To mitigate pervasive monitoring, new protocols should have only secure versions.
Isn't this the direction newer protocols are taking? AFAIK HTTP 2.0 is always encrypted (even if no SSL cert is installed)
For the mentioned protocols: most IMAP and SMTP servers (which enable TLS) disregard the IETF and allow TLS-on-connect connections on ports 993 and 465 respectively. If the IETF would (again) standardize this the problem would be reasonably solved.
> Isn't this the direction newer protocols are taking? AFAIK HTTP 2.0 is always encrypted (even if no SSL cert is installed)
Using ad-hoc certificated is as safe as using STARTTLS: a MITM can just put his own cert (similar to a MITM removing the STARTTLS capability announcement from the client to the server). It's actually worse, since the client will think it's communication is safer than it actually is.
This is a matter of UI design, then. Eventually I'd expect secure sites to be the default (with broken lock symbols in the URL bar if not), with higher levels of security carrying something like the secure site symbols we see today.
Encryption and identity assurance are two different things - you can easily have the first which makes passive monitoring much more difficult without the trust infrastructure to mitigate MITMing.
For the average user, knowing what we know now, I'd say the first is a much more clear and present danger. The second requires a person to actually take interest in your traffic.
Comments
Isn't this the direction newer protocols are taking? AFAIK HTTP 2.0 is always encrypted (even if no SSL cert is installed)
For the mentioned protocols: most IMAP and SMTP servers (which enable TLS) disregard the IETF and allow TLS-on-connect connections on ports 993 and 465 respectively. If the IETF would (again) standardize this the problem would be reasonably solved.
Using ad-hoc certificated is as safe as using STARTTLS: a MITM can just put his own cert (similar to a MITM removing the STARTTLS capability announcement from the client to the server). It's actually worse, since the client will think it's communication is safer than it actually is.
This is a matter of UI design, then. Eventually I'd expect secure sites to be the default (with broken lock symbols in the URL bar if not), with higher levels of security carrying something like the secure site symbols we see today.
Encryption and identity assurance are two different things - you can easily have the first which makes passive monitoring much more difficult without the trust infrastructure to mitigate MITMing.
For the average user, knowing what we know now, I'd say the first is a much more clear and present danger. The second requires a person to actually take interest in your traffic.
My understanding is that in HTTP/2.0 encryption will be optional. But that Chrome and Firefox at least will require it.