3 ms·

> That said, I don't know how or if "pervasive monitoring" is mitigated any differently than plain old MITMs. The difference is that with passive monitoring, y

by cnst 12y ago

> That said, I don't know how or if "pervasive monitoring" is mitigated any differently than plain old MITMs. The difference is that with passive monitoring, you don't have to worry about authentication, and opportunistic encryption without any sort of authentication is good enough. Think STARTTLS in SMTP. I actually found this RFC7258 through http://tools.ietf.org/html/draft-nottingham-http2-encryption-03 http://tools.ietf.org/html/draft-nottingham-http2-encryption... "Opportunistic Encryption for HTTP URIs", so, there's that. Personally very interested in this, as I have a dozen of different domains and subdomains for my non-profit reference web-sites like http://mdoc.su/ http://mdoc.su/, and I also care about supporting legacy clients and having minimal administrative costs, hence I cannot deploy HTTPS://.

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 ago
  Your 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!

by cnst 12y ago

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 ago
Your 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!