[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Long] A history of Netscape/MSIE problems

Tom wrote,

>Hallam-Baker wrote:
>> There was a long list of security holes in SSL, PCT plugged a good
>> number of them and SSL v3 plugged a few.

>This statement surprises me.  It appears to mean that you think PCT has
>fewer holes than SSL 3.0.  If you know of any holes in SSL 3.0, I'd be
>very interested in hearing about them.

Sorry Tom, should have made a bit clearer the difference between the 
pre-Weinstein/El-Gamal and post era a little better. Also what I 
meant to say was that SSLv3 plugged a few that PCT had done differently.

The remaining probnlems as I see it are of approach. The security in
SSL is not in the right layer to support collaboration. Thats not to say
its a bad thing to have SSL and SSL makes a lot more sense to me than
IP-SEC does, but then I always prefer security thats higher in the
protocol stack. SSL strikes me as a credible prospect for pervasive
low level security across all IP protocols while IP-sec would be nice
but will probably take a decade to become ubiquitous.

The problem with SSL is that using a public key based protocol to 
protect a password is something of a technology mismatch. I want
the flexibility that public key auth gives me available at the 
application level.

There is no real model for how SSL provides security in a distributed
authoring environment. If I want to distribute encrypted documents
from one server and keys from another, have an authoring tool sign
a document in a non repudiable manner and integrate that through to
the authorisation system there is not really a means to do it.

I don't think that S-HTTP helps either, its too baroque. If all one
wants to do is sign a document being transmitted in http then whats
wrong with a Content-Signature: tag? If you want to encrypt on a 
symmetric key which is known to the firewall and want the firewall
to know what is going on then whats wrong with using chunked encoding?
Similarly whats wrong with a simple MAC function signing each message
body? If one incorporates a wrapping mechanism then one can control 
the level of security in an arbitary manner, exposing or concealing
as much as one wants. I've never understood why S-HTTP needed so much
mechanism to achieve all that.