in reply to Re: Re: Adding a password to Zip compression ?
in thread Adding a password to Zip compression ?

I guess I could setup another path/directory, and the user _has_ to use the SSL connection, plus a .htaccess login. Would that make the viewing of the information 'secure' ?

I always understood that all SSL connections are encrypted including the sending/receiving of logins and passwords. It will be as secure as SSL.

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

  • Comment on Re: Re: Re: Adding a password to Zip compression ?

Replies are listed 'Best First'.
Re: Re: Re: Re: Adding a password to Zip compression ?
by u914 (Pilgrim) on Jan 04, 2004 at 20:09 UTC
    Yes, that's essentially correct.

    If the directory is in an ssl-protected place, then the challenge/response (ie, the user/pass sent over the network) will be encased within the cryptographic sleeve.

    It goes something like this:

    1. browser makes an https request (ie, tries to access an https/ssl webpage)
    2. webserver responds with server certificate and encryption keys (public key)
    3. browser examines (sometimes with user intervention) the certificate, and accepts the session key
    4. a secure connection (cryptographic sleeve) is created; all traffic between the client/browser and server is encrypted
    5. if the .htaccess is set to require http basic auth, the basic auth challenge is presented (ie, user/pass dialog appears)
    6. user/pass is passed to server, inside SSL crypto sleeve
    7. if valid, server returns contents of requested location, also protected by SSL

    and so forth ad nauseum...

[reply]
Re: Re: Re: Re: Adding a password to Zip compression ?
by exussum0 (Vicar) on Jan 04, 2004 at 22:58 UTC
    It is secure as a man-in-the-middle attack. He doens't have to act as a proxy, but if he can capture and reconstruct the end results of the transmitted data.. it's not all that secure. It's because the key creation, unless cert's are used on the client end, are negotiated, the negotiation can be replayed. If a client and a server both have cert's, then they'll use PKI... similar to GPG/PGP in effect.

    Play that funky music white boy..
[reply]
Re: Re: Re: Re: Adding a password to Zip compression ?
by peterr (Scribe) on Jan 06, 2004 at 02:45 UTC
    Hi,

    I always understood that all SSL connections are encrypted including the sending/receiving of logins and passwords. It will be as secure as SSL.

    Sorry, I didn't explain it too well. At present, the user does have a login (.htacess,etc), and he accesses it like this

    http://example.com/userloginpath

    which, as I understand, still sends the user/pwd across the 'net as plain text. What I would like to do is to _force_ it to be

    https://example.com/userloginpath

    .. although he doesn't have SSL, I do, so using mine on a shared basis

    https://mydomain/example.com/userloginpath

    Peter

[reply]
      Perhaps a job for the mod_rewrite engine of Apache? I think (without having tried it yet) that you can force such redirections by writing some rewriting rules.

      CountZero

      "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

[reply]
        Perhaps a job for the mod_rewrite engine of Apache? I think (without having tried it yet) that you can force such redirections by writing some rewriting rules.

        Yes, could be. Although I don't have access to, what's the file called, ..httpd.conf or something like that, I have been able to use .htacess and mod_rewrite successfully, so I will find out how to "force" that. :)

        Peter

[reply]

In Section Seekers of Perl Wisdom