3 ms·
In your last paragraph, you've actually provided a good example of why opportunistic encryption is dangerous. Instead of deploying proper HTTPS, you're thinking
by dchest 12y ago
In your last paragraph, you've actually provided a good example of why opportunistic encryption is dangerous. Instead of deploying proper HTTPS, you're thinking that opportunistic encryption is good enough for you, that it is a valid replacement for HTTPS.
- belorn 12y agoYour comment provide an excellent example why current views of HTTPS is dangerous to security. It diffuses the line between encryption, authentication and trust. Opportunistic encryption adds encryption as a fundamental part of the network, where HTTPS create added features on top of an primitive network design. So long one understand what HTTPS do, putting encryption into the transport layer will highlight HTTPS as an authentication system and make network security more understandable, reliable, and in the long run, better.
- cnst 12y ago> Instead of deploying proper HTTPS, you're thinking that opportunistic encryption is good enough for you, that it is a valid replacement for HTTPS. But I will never deploy HTTPS:// regardless -- no backwards compatibility with http-only clients, not even much compatibility with HTTPS-enabled clients with no SNI support (e.g. Android 2.3 or Windows XP), the tie-in of the new address scheme, huge opportunity costs for non-commercial multi-dozen-site owners (certificates for wildcard domains like "*.example.net" cost several times more than the domain names themselves; plus the multi-domain certificates for both both "example.net" and "example.com" simultaneously (to avoid having to deal with SNI) cost even more, and those 50$+/domain for multi-domain certs don't even seem to have wildcard support, either). So, even though I will never deploy HTTPS://, you think opportunistic encryption is still a waste of time for me? IETF now begs to differ! And I'm very glad they finally do!