Re: TLS/SSL patch (alpha)

[Richard Levitte - VMS Whacker]

From: "Derek R. Price" <dprice@collab.net>

dprice> >    6) TLS/SSL uses packets, not byte-wise transmission, and it's
dprice> >       possible this holds surprises for us....
dprice> 
dprice> Nothing insurmountable, I assume...

Hardly.  Since TCP/IP itself is packet-based but can still be used for
streams on a higher level, I don't see a problem doing the saem with
SSL/TLS.  When using OpenSSL, one can place a buffering BIO on top of
the SSL/TLS object and thereby have working buffering.

dprice> >    5) support for session resumption?  Since the client is usually
dprice> >       run as a series of separate processes, I don't know if this
dprice> >       is practical.
dprice> 
dprice> Why would this be desirable?

I assume that "resumption" means "reuse".  The reason this exists at
all is that PK authentication takes time (RSA verifications and so
on).  And certificate path discovery and verification adds more to
that time.  Session reuse assumes that both the client and the server
have done a proper SSL/TLS handshake and have come up with a session
key for the encrypted channel.  The next time the client connects to
the same server, it can try telling the server what session id (not
the same as the session key!) it has and try to communicate using the
corresponding session key (which must be stored by server and client
separately).  If it works, fine!  If not, or the server refuses to
recognise the session id, a proper handshake is started so a new
session gets created.

Personally, I don't really see that as an option for CVS, as the
client may be started with quite some time between the runs, and also,
the session data would have to be stored on non-volatile media on the
client side, with the obvious security hole that opens.

dprice> >    7) For the truly paranoid, should we support automatic SSL key
dprice> >       renegotiation?
dprice> 
dprice> If not overly complicated, we should always cater to the
dprice> paranoid.  A configurable option would be best - not sure
dprice> whether this should be client, server, or both...

This would only be needed of session reuse is put in place.
Otherwise, CVS runs are sufficiently short to not have a security
problem with looooong session times.

My recommendation is that you don't bother with session reuse of SSL
key renegotiations.

-- 
Richard Levitte   \ Spannvägen 38, II \ LeViMS@stacken.kth.se
Chairman@Stacken   \ S-168 35  BROMMA  \ T: +46-8-26 52 47
Redakteur@Stacken   \      SWEDEN       \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis                -- poei@bofh.se
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, GemPlus:             http://www.gemplus.com/

Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.