Peter, Peter Djalaliev wrote:
Apache/mod_ssl version 2.2.0 implements RFC2817 in a way that, I believe, prevents MITM attacks. The RFC itself admits the possibility for a MITM attack, but only when the server is willing to provide some resource both through HTTP or through HTTPS to start with. In mod_ssl, the SSL upgrade is used together with SSLRequireSSL, so the resource cannot be obtained unless an SSL is established first.
The problem is that the security depends entirely on the server deciding not to serve the content over plain unencrypted HTTP . The client has no control. If the server is misconfigured, or there is an MITM, the client will go through with an unencrypted HTTP connection.
In the old discussion thread from netscape.public.mozilla.crypto Julien Pierre said that he doesn't believe that the http scheme is sufficient to provide the secutiry provided by https. I am not sure I quite understand that. Are the 'http' and 'https' schemes inherently different? Aren't they the same on the application level, but different only in the underlying transport protocol - TCP for http and TLS for https? Can somebody explain me this?
Yes, they are only different in the transport. However, security cannot be considered to be outside the scope of the application . In many cases it is inherent to it. For example, think banking. If your application has a security requirement, then you don't want to leave it to chance whether you are going to get a secure connection or not. You need something that tells the browser that security is required in your application, so that it can enforce it, and not just the server. The https protocol scheme, as imprecise as it is, tells the client only to establish secure connections. The http protocol scheme specifies plaintext connections. There is no protocol scheme you can include in an HTML form to tell the client "go to this server and do a TLS upgrade. don't fall back to plaintext HTTP". That's what makes it unsuitable.
Also, think of banks that create HTML login forms which you obtain with a plaintext HTTP connection. This is ugly to begin with. But at least, those forms contain HTTPS links, and if you have your browser set not to submit anything unencrypted, then you will get a pop-up before you submit your login and password telling you it's insecure. With TLS upgrade, the client will POST the data unencrypted, even if the server requires TLS upgrade, just because the form said so. It will go in the clear anywhere.
This is why IMO the TLS upgrade as currently specified should not be implemented in general-purpose web browsers and servers. Once there is a differentiator on the client side that browser can clearly interpret, then it will be suitable. I suggested using "httpt" (t for TLS ugprade) . But there wasn't strong support for this in the HTTP working group, so I didn't write a draft. It doesn't seem that there has been much demand for it in the last 6 years since the discussion occurred.
RFC2817 also talks about another advantage of this upgrade mechanism - providing the hostname during the initial TLS handshake. This feature is also included as a TLS extension in RFC3546, but is RFC3546 widely implemented? NSS doesn't implement it as far as I know...are there any plans about this? Are there any issues/concerns about the TLS extension mechanism?
There is ongoing work on the server name indication extension in NSS, at least for the client side for now. Nelson can tell you more.
In the Apache/mod_ssl discussion forums, somebody said that optional SSL upgrades would allow for more compact, modular security services to be implemented - I interpret this as securty-on-demand. Do you think this could be an advantage - would we lose on security if we make it optional?
Yes, we very much lose on security if it's optional. Nobody will know if their application is secure or not.
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
