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.
I am working on porting the same implementation to mod_nss (in the meantime I had multiple people tell me that they don't like it and that it is evil :))) ). Resources available to obtain after an SSL upgrade can be protected on a per-directory basis with SSLRequireSSL. The concept, however, can be extended to consider, for example, extended attributes in Linux/UNIX file systems. It would provide a better granularity, but then I guess it might not be portable accross platforms - I don't know how other OS-s implement extended attributes.
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?
Another major concern that I remember reading about was compatibility with current web browsers. In Apache's implementation of TLS upgrades, the server generates HTML code that explains to the user that the web server has requested an upgrade which is not supported by the user's client. When the browser receives a HTTP response with a 426 status code that it doesn't understand, it should use the default process scenario and just display that above-mentioned HTML code to the client - a quite grace degradation I think. I know that Firefox does this - in the ProcessResponse() routine of nsHttpChannel. I haven't been able to test this with other browsers, but to me it seems like a very reasonable to handle unsupported SSL upgrade requests.
>From reading RFC2817, I get that one of the main purposes for this standard is to eliminate the duplicate port numbers(80/443, 21/990 etc). What do people think about the advantages of this - is it effective/reasonable/necessary...? This goes back to Julien's comment about http being insufficient as a scheme.
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?
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? Would it be "optional" even then - we can protect all content with a mechanism like SSLRequireSSL, or extended attributes with security policies... What do you think about this?
Are there any other major concerns about RFC2817 that I haven't touched on? I don't understand proxies that much, so I don't know if using the CONNECT method for hop-by-hop upgrades has any disadvantages - does it? Does it impose a performance overhead?
Regards,
Peter
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
