3 ms·

The argument isn't whether encryption without authentication is useless, but whether encryption without authentication is significantly worse than useless and i

by halo 16y ago

The argument isn't whether encryption without authentication is useless, but whether encryption without authentication is significantly worse than useless and is therefore deserving of Firefox's awkward hoop-jumping UI. I'm not convinced. I think there is potentially some middle ground to be found (e.g. a URL prefix which works over SSL but makes no implication of security) but clearly Mozilla decided that making it really irritating without any workaround was the best solution to the problem, regardless of any collatoral damage it causes.

tptacek 16y ago
This is not a hard concept to understand. You can't have secure encryption without trustworthy keys. Without the "authentication" functionality of SSL, you can't trust keys, because a man in the middle can simply swap them out of your session. When we say "you can't have encryption without authentication", we mean that every mechanism for agreeing on an AES key with a counterparty over the Internet relies on some form of authentication.
- halo 16y ago
  I understand the concept. I don't understand why you're pointing out the obvious to me, nor how your reply is a relevent response to my post. I'm asking why an insecure SSL connection is worse than an insecure HTTP connection. If they are both completely insecure, why does Firefox turn one of them into a compete UI nightmare? If the reasoning is that https:// https:// somehow implies security, then the obvious and sensible solution is to create a new prefix for insecure SSL sites such as httpu://, and throw up a warning page when visiting the https version that links to the insecure SSL version. I see this as being preferable to the awkward and annoying way Firefox treats self-signed certificates at the moment. I also suspect that had Mozilla taken the lead, the major browsers would have followed suit.
  - tptacek 16y ago
    The plain HTTP connection doesn't claim to offer any security. You know not to give it your credit card number or password. What trust can you extend the "poorly encrypted" protocol?
    - halo 16y ago
      You should give it the exact same amount of trust as a plain HTTP connection. Which is exactly my point.
      - burgerbrain 16y ago
        Then why the hell would you even use it? The fact is, even if the browser so much as displays "https" in the addressbar, you are giving the unknowlegable user a form of positive feedback when none whatsoever is warrented. Strong netagive feedback is a much more appropriate solution.
        _delirium 16y ago
        It filters out some kinds of common attacks, e.g. most (all?) uses of Firesheep session-cookie snooping at coffee shops. Of course, for us nerd types https isn't really necessary for that, because I can just websurf over an ssh -D proxy to a VPS, to encrypt the coffee-shop side of the link.
        jodrellblank 16y ago
        You would use it because it makes encrypted traffic on the network the norm. It makes it impossible to decipher your traffic without an active deliberate security attack instead of a passive sniffing session. It means when a traffic sniffer happens on your traffic they will get (plain text, encrypted data) and they won't know whether the encrypted data is 'good' or 'bad' and will have an easier time with the plain text - the "just have to run faster than the other guy" approach.
        tptacek 16y ago
        It's not encrypted if the keys aren't secure.
        deleted 16y ago
        [deleted]
        deleted 16y ago
extension 16y ago
Browsers are already having a really hard time making users of average proficiency understand SSL feedback and act wisely in response to warnings. Whatever special case they add to the UI to accomodate geeks using self-signed certs becomes yet another complexity that the normal user has to understand. Also, consider that there are probably some users who think they understand the implications of trusting a self-signed cert while they actually do not, and the browser has no way of differentiating this.

by halo 16y ago

tptacek 16y ago

This is not a hard concept to understand. You can't have secure encryption without trustworthy keys. Without the "authentication" functionality of SSL, you can't trust keys, because a man in the middle can simply swap them out of your session. When we say "you can't have encryption without authentication", we mean that every mechanism for agreeing on an AES key with a counterparty over the Internet relies on some form of authentication.

halo 16y ago
I understand the concept. I don't understand why you're pointing out the obvious to me, nor how your reply is a relevent response to my post. I'm asking why an insecure SSL connection is worse than an insecure HTTP connection. If they are both completely insecure, why does Firefox turn one of them into a compete UI nightmare? If the reasoning is that https:// https:// somehow implies security, then the obvious and sensible solution is to create a new prefix for insecure SSL sites such as httpu://, and throw up a warning page when visiting the https version that links to the insecure SSL version. I see this as being preferable to the awkward and annoying way Firefox treats self-signed certificates at the moment. I also suspect that had Mozilla taken the lead, the major browsers would have followed suit.
- tptacek 16y ago
  The plain HTTP connection doesn't claim to offer any security. You know not to give it your credit card number or password. What trust can you extend the "poorly encrypted" protocol?
  - halo 16y ago
    You should give it the exact same amount of trust as a plain HTTP connection. Which is exactly my point.
    - burgerbrain 16y ago
      Then why the hell would you even use it? The fact is, even if the browser so much as displays "https" in the addressbar, you are giving the unknowlegable user a form of positive feedback when none whatsoever is warrented. Strong netagive feedback is a much more appropriate solution.
      - _delirium 16y ago
        It filters out some kinds of common attacks, e.g. most (all?) uses of Firesheep session-cookie snooping at coffee shops. Of course, for us nerd types https isn't really necessary for that, because I can just websurf over an ssh -D proxy to a VPS, to encrypt the coffee-shop side of the link.
      - jodrellblank 16y ago
        You would use it because it makes encrypted traffic on the network the norm. It makes it impossible to decipher your traffic without an active deliberate security attack instead of a passive sniffing session. It means when a traffic sniffer happens on your traffic they will get (plain text, encrypted data) and they won't know whether the encrypted data is 'good' or 'bad' and will have an easier time with the plain text - the "just have to run faster than the other guy" approach.
        tptacek 16y ago
        It's not encrypted if the keys aren't secure.
        deleted 16y ago
        [deleted]
        deleted 16y ago

extension 16y ago

Browsers are already having a really hard time making users of average proficiency understand SSL feedback and act wisely in response to warnings. Whatever special case they add to the UI to accomodate geeks using self-signed certs becomes yet another complexity that the normal user has to understand. Also, consider that there are probably some users who think they understand the implications of trusting a self-signed cert while they actually do not, and the browser has no way of differentiating this.