Re: [Long] A history of Netscape/MSIE problems
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. -- You should only break rules of style if you can | Tom Weinstein coherently explain what you gain by so doing. | tomw@netscape.com
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. Phill
participants (2)
-
hallam@ai.mit.edu -
Tom Weinstein