6 ms·

Should Firefox throw a generic warning for a 5 minute expired certificate for Wikipedia? I think it's time to split encryption protocols. The defacto default o

by Joakal 16y ago

Should Firefox throw a generic warning for a 5 minute expired certificate for Wikipedia? I think it's time to split encryption protocols. The defacto default of non-encryption instead of encryption due to big browser warnings are preventing web developers from implementing any encryption at all. The browsers are indirectly allowing anyone to snoop on what you view on the non-encrypted websites. I want to use some basic encryption on my connection rather than no encryption when visiting websites like Wikipedia.

jmillikin 16y ago
> Should Firefox throw a generic warning for a 5 minute > expired certificate for Wikipedia? Absolutely. > I want to use some basic encryption on my connection > rather than no encryption when visiting websites like > Wikipedia. Then use Wikipedia's secure URL at https://secure.wikimedia.org/wikipedia/en/wiki/Main_Page https://secure.wikimedia.org/wikipedia/en/wiki/Main_Page Encryption without authentication is useless. If mybank.com only supports encryption, I have no idea whether I'm actually connected to mybank.com , or to the guy running tcpdump in the next booth. Firefox gets a lot of grief (from idiots) for refusing self-signed certificates by default, but it's a huge credit to their security team that they've resisted the pressure to ease up.
- Herring 16y ago
  The extension https everywhere auto-encrypts wikipedia https://www.eff.org/https-everywhere https://www.eff.org/https-everywhere
- Joakal 16y ago
  Well, they are also a huge credit to preventing encryption from becoming the standard for all websites by ignoring 'idiots' and I'm talking non-banks like Wikipedia. Are you happy to visit a John Doe blog with no encryption because he didn't want to pay for a certificate?
  - jmillikin 16y ago
    I'd rather have an unencrypted connection than encrypted to an unknown endpoint. If John Doe's blog is sensitive enough to require a secure connection, he can use one of the free certificate vendors like StartSSL.
- kevinchen 16y ago
  Those people aren't "idiots," they're normal (non-geek) people. They just want to buy stuff on Amazon or whatever and not have their credit card number stolen.
  - jmillikin 16y ago
    Re-read my post -- the idiots are people who believe Firefox should accept self-signed certificates by default. Amazon has nothing to do with this.
    - kevinchen 16y ago
      Forget the Amazon example (there are plenty of legit sites that self-sign, like my school's online grading system). It scares the hell out of your average computer user, and it doesn't provide much gain.
- julian37 16y ago
  Encryption without authentication is useless. If mybank.com only supports encryption, I have no idea whether I'm actually connected to mybank.com , or to the guy running tcpdump in the next booth. Well, of course encryption without authentication is useless for authentication. It is still useful for encryption, though :-)
  - tptacek 16y ago
    No, it's not. To encrypt data between two parties who don't know each other, both sides have to agree on a key. There is no protocol that does that securely in the presence of a man in the middle without a "tiebreaker"; the tiebreaker SSL PKI uses is certificates.
    - julian37 16y ago
      But doesn't (unauthenticated) encryption at least protect against eavesdroppers who don't have the ability to modify the stream, i.e. to mount a MITM attack?
      - caf 16y ago
        "eavesdroppers who don't have the ability to modify the stream" are a nice fairytale, but they don't really exist in practice, with current network protocols. DNSSEC might change this, once it becomes universal.
        julian37 16y ago
        What about Firesheep users? Surely there are many people who find it a lot easier to just capture some WiFi traffic via libpcap, WireShark or the like than to set up a fake WiFi access point, poison a DNS cache or mount other such attacks that would allow them to actually modify traffic.
        tptacek 16y ago
        Why are we talking about defenses that are defeated by just a couple lines of code? Firesheep could use pcap_write in addition to pcap_loop and redirect connections. What's the point of a defense that breaks Firesheep 1.0 only to fall to Firesheep 2.0?
- 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?
- tbrownaw 16y ago
  Encryption without authentication is useless. It's mostly useless. Anyone trying to eavesdrop needs to expend slightly more resources, and needs to take the risk that there was some out-of-band authentication that they aren't aware of. Firefox gets a lot of grief (from idiots) for refusing self-signed certificates by default, but it's a huge credit to their security team that they've resisted the pressure to ease up. No, it mostly gets grief (from sane people) for not also refusing plain HTTP under the same pretenses.
  - jmillikin 16y ago
    An invalid certificate is far more likely to be an attack than a misconfigured server. If Firefox silently accepted self-signed certificates, and presented the same UI as an unencrypted page, attackers could intercept requests to https://paypal.com/ https://paypal.com/ and very few users would ever notice. Additionally, automatically accepting self-signed certificates would render ideas like "HTTPS-only cookies" useless, because now the browser would happily send them to anyone who asks.
    - __david__ 16y ago
      > An invalid certificate is far more likely to be an attack than a misconfigured server. I don't believe that. I've run into tons of self signed/invalid certs that weren't attacks. If you're implicitly limiting your statement to large sites (paypal, amazon and the like) then you're probably right. But unqualified, it is definitely not the case.
  - tptacek 16y ago
    Plain HTTP isn't lying to the end-user.
    - jodrellblank 16y ago
      Would you support if browsers made password fields not-starred-out on HTTP sites? Just to make it clear that there is no implication of security there?
- pyre 16y ago
  The argument against self-signed certificates seems to be that people will get a false sense of security because they think that the connection is 'secure.' How about accepting the connection but not displaying the normal visual cues that say "this site is secure?" (e.g. the lock icon) Is that a significantly worse alternative? The argument that encryption without authentication is useless seems to be too focused on the security of the connection. The larger the percentage of network traffic that is actually encrypted the less 'suspicious' encrypted connections look. In general, this is a state of affairs that we want to get to. Using encryption shouldn't make you stand out from the general population. How is connecting to a site using HTTP any more secure than connecting to a site with HTTPS and a self-signed certificate so long as the user is not presented with any indication that the site is now 'secure?' Even better, how about having an icon that is always in one of two states: "secure" or "insecure." So now the user is presented with something that indicates "insecure" even when they are browsing over HTTP. This more accurately represents the state of affairs. The way browsers present security to the user currently is more along the lines of: HTTP => I can browse the web and login to Facebook HTTPS (CA-signed cert) => I can now use my credit card HTTPS (self-signed cert) => ZOMG! I'M BEING HACKED!
tptacek 16y ago
What's the point of encrypting HTTP if any man in the middle can decrypt it? The whole point of the deck you (hopefully) read is that HTTPS falls to MITM attacks. Authentication and confidentiality aren't just two "features" of a protocol. You have to have some degree of both, or you're just wanking.
- Joakal 16y ago
  The default standard as it exists is non-encryption. Browsers throw warnings for invalid certificates of a bank, wikipedia, random blog, etc. Not unencrypted connections like a random website like a John Doe blog. The crux of the issue is privacy in browsing. Some parts of Wikipedia are pseudo-illegal to view in some parts of the world. Viewing it would put the user on the watchlist or more.
  - tptacek 16y ago
    How does it help the user to lie to him and tell him his stuff is encrypted, when in fact he'd have absolutely no way to know whether his keys were force-fed to his browser by his government?

by Joakal 16y ago

jmillikin 16y ago

> Should Firefox throw a generic warning for a 5 minute > expired certificate for Wikipedia? Absolutely. > I want to use some basic encryption on my connection > rather than no encryption when visiting websites like > Wikipedia. Then use Wikipedia's secure URL at https://secure.wikimedia.org/wikipedia/en/wiki/Main_Page https://secure.wikimedia.org/wikipedia/en/wiki/Main_Page Encryption without authentication is useless. If mybank.com only supports encryption, I have no idea whether I'm actually connected to mybank.com , or to the guy running tcpdump in the next booth. Firefox gets a lot of grief (from idiots) for refusing self-signed certificates by default, but it's a huge credit to their security team that they've resisted the pressure to ease up.

Herring 16y ago
The extension https everywhere auto-encrypts wikipedia https://www.eff.org/https-everywhere https://www.eff.org/https-everywhere
Joakal 16y ago
Well, they are also a huge credit to preventing encryption from becoming the standard for all websites by ignoring 'idiots' and I'm talking non-banks like Wikipedia. Are you happy to visit a John Doe blog with no encryption because he didn't want to pay for a certificate?
- jmillikin 16y ago
  I'd rather have an unencrypted connection than encrypted to an unknown endpoint. If John Doe's blog is sensitive enough to require a secure connection, he can use one of the free certificate vendors like StartSSL.
kevinchen 16y ago
Those people aren't "idiots," they're normal (non-geek) people. They just want to buy stuff on Amazon or whatever and not have their credit card number stolen.
- jmillikin 16y ago
  Re-read my post -- the idiots are people who believe Firefox should accept self-signed certificates by default. Amazon has nothing to do with this.
  - kevinchen 16y ago
    Forget the Amazon example (there are plenty of legit sites that self-sign, like my school's online grading system). It scares the hell out of your average computer user, and it doesn't provide much gain.
julian37 16y ago
Encryption without authentication is useless. If mybank.com only supports encryption, I have no idea whether I'm actually connected to mybank.com , or to the guy running tcpdump in the next booth. Well, of course encryption without authentication is useless for authentication. It is still useful for encryption, though :-)
- tptacek 16y ago
  No, it's not. To encrypt data between two parties who don't know each other, both sides have to agree on a key. There is no protocol that does that securely in the presence of a man in the middle without a "tiebreaker"; the tiebreaker SSL PKI uses is certificates.
  - julian37 16y ago
    But doesn't (unauthenticated) encryption at least protect against eavesdroppers who don't have the ability to modify the stream, i.e. to mount a MITM attack?
    - caf 16y ago
      "eavesdroppers who don't have the ability to modify the stream" are a nice fairytale, but they don't really exist in practice, with current network protocols. DNSSEC might change this, once it becomes universal.
      - julian37 16y ago
        What about Firesheep users? Surely there are many people who find it a lot easier to just capture some WiFi traffic via libpcap, WireShark or the like than to set up a fake WiFi access point, poison a DNS cache or mount other such attacks that would allow them to actually modify traffic.
        tptacek 16y ago
        Why are we talking about defenses that are defeated by just a couple lines of code? Firesheep could use pcap_write in addition to pcap_loop and redirect connections. What's the point of a defense that breaks Firesheep 1.0 only to fall to Firesheep 2.0?
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?
tbrownaw 16y ago
Encryption without authentication is useless. It's mostly useless. Anyone trying to eavesdrop needs to expend slightly more resources, and needs to take the risk that there was some out-of-band authentication that they aren't aware of. Firefox gets a lot of grief (from idiots) for refusing self-signed certificates by default, but it's a huge credit to their security team that they've resisted the pressure to ease up. No, it mostly gets grief (from sane people) for not also refusing plain HTTP under the same pretenses.
- jmillikin 16y ago
  An invalid certificate is far more likely to be an attack than a misconfigured server. If Firefox silently accepted self-signed certificates, and presented the same UI as an unencrypted page, attackers could intercept requests to https://paypal.com/ https://paypal.com/ and very few users would ever notice. Additionally, automatically accepting self-signed certificates would render ideas like "HTTPS-only cookies" useless, because now the browser would happily send them to anyone who asks.
  - __david__ 16y ago
    > An invalid certificate is far more likely to be an attack than a misconfigured server. I don't believe that. I've run into tons of self signed/invalid certs that weren't attacks. If you're implicitly limiting your statement to large sites (paypal, amazon and the like) then you're probably right. But unqualified, it is definitely not the case.
- tptacek 16y ago
  Plain HTTP isn't lying to the end-user.
  - jodrellblank 16y ago
    Would you support if browsers made password fields not-starred-out on HTTP sites? Just to make it clear that there is no implication of security there?
pyre 16y ago
The argument against self-signed certificates seems to be that people will get a false sense of security because they think that the connection is 'secure.' How about accepting the connection but not displaying the normal visual cues that say "this site is secure?" (e.g. the lock icon) Is that a significantly worse alternative? The argument that encryption without authentication is useless seems to be too focused on the security of the connection. The larger the percentage of network traffic that is actually encrypted the less 'suspicious' encrypted connections look. In general, this is a state of affairs that we want to get to. Using encryption shouldn't make you stand out from the general population. How is connecting to a site using HTTP any more secure than connecting to a site with HTTPS and a self-signed certificate so long as the user is not presented with any indication that the site is now 'secure?' Even better, how about having an icon that is always in one of two states: "secure" or "insecure." So now the user is presented with something that indicates "insecure" even when they are browsing over HTTP. This more accurately represents the state of affairs. The way browsers present security to the user currently is more along the lines of: HTTP => I can browse the web and login to Facebook HTTPS (CA-signed cert) => I can now use my credit card HTTPS (self-signed cert) => ZOMG! I'M BEING HACKED!

tptacek 16y ago

What's the point of encrypting HTTP if any man in the middle can decrypt it? The whole point of the deck you (hopefully) read is that HTTPS falls to MITM attacks. Authentication and confidentiality aren't just two "features" of a protocol. You have to have some degree of both, or you're just wanking.

Joakal 16y ago
The default standard as it exists is non-encryption. Browsers throw warnings for invalid certificates of a bank, wikipedia, random blog, etc. Not unencrypted connections like a random website like a John Doe blog. The crux of the issue is privacy in browsing. Some parts of Wikipedia are pseudo-illegal to view in some parts of the world. Viewing it would put the user on the watchlist or more.
- tptacek 16y ago
  How does it help the user to lie to him and tell him his stuff is encrypted, when in fact he'd have absolutely no way to know whether his keys were force-fed to his browser by his government?