<<< Date Index >>>     <<< Thread Index >>>

Re: [Dovecot] Trying to explain mutt+dovecot(ssl) to myself :(



On Mon, Apr 23, 2007 at 09:37:38PM +0800, Wilkinson, Alex wrote:
> Hi all,
> 
> I have recently migrated my mail from courier-imap to dovecot.
> In doing so, I finally configured mutt to connect to imaps (SSL).
> 
> In the end I got it all working. I then sat back and thought:
> "I kinda don't understand the SSL/TLS part even though it works".
> And I hate setting stuff up and not truely understanding the
> mechanics of it.
> 
> So I started to write about it and am stuck. Can those that
> _understand_ mutt+ssl have a read of what I wrote to myself and
> give me your $00.02 worth (corrections etc).
> 
>     Trying to explain mutt+ssl and getting it all wrong
>     ---------------------------------------------------
> 
>     * mutt(with openssl support built in) initiates with a "SSL-Client-Hello" 
> to SSL on port 993
>       i.e. mutt's capabilities (algorithms, SSL version etc).
> 
>     * dovecot:993 compares mutt's CipherSuites with its own. Of the 
> CipherSuites mutt and dovecot
>       have in common, dovecot:993 chooses the _most_ secure algorithm.
> 
>     * Dovecot:993 will then tell mutt what it has decided to use and assigns 
> a Unique session ID.
>       From now on all communication is via this ID.
> 
>     * Now that the CipherSuite is set between mutt and dovecot, dovecot sends 
> its SSL certificate
>       to mutt [/usr/local/share/dovecot/certs/dovecot.pem].
>       mutt then uses dovecot's corresponding public key 
> [/usr/local/share/dovecot/private/dovecot.pem]
>       to verify that the ceritificate is authentic.
> 
>     * once mutt has verified that the certificate is authentic
> 
>     ... and here I got unstuck.
> 

I'm doing a similar migration, and am interested in this thread.
Presumably its not just Mutt which would need to operate in this fashion,
it's everything which uses openSSL as the basis of its secure communication.

What I *think* *should* happen thereafter is:

        The Client generates a 'one-time' key based on a random number and the
        negotiated encryption algorithm

        The key is encrypted using the server's public key, and transmitted to
        the server (its too costly to do bulk encryption using public-key 
methods)

        The server decrypts this encrypted 'one-time' key (which only the
        server can do)

        All further traffic between client and server is encrypted using
        this 'one-time' key.

        (There can be periodic new 'one-time' keys generated as an extra
         means of helping to prevent man-in-the-middle attacks)

That's how I understand things to work in openSSL, but I too find the whole
business difficult to grasp.

Cheers,
Terry


> Cheers
> 
>  -aW
> 
> IMPORTANT: This email remains the property of the Australian Defence 
> Organisation and is subject to the jurisdiction of section 70 of the CRIMES 
> ACT 1914.  If you have received this email in error, you are requested to 
> contact the sender and delete the email.
> 
> 

--