10 ms·

Chrome should change the lock icon to something weaker for sessions that don't use ephemeral keys. This may be the most important article on HN related to the

Chrome should change the lock icon to something weaker for sessions that don't use ephemeral keys. This may be the most important article on HN related to the NSA leaks. Fact is, most of us haven't paid enough attention to the details of https. EDIT: "something weaker" - didn't mention color. People dont need to understand "forward secrecy", the browser just needs to raise the bar for what's considered secure. The goal is to change server-side behavior, not consumer behavior.

jiggy2011 13y ago
How do you explain that to people though? It's simple enough to say "if you don't see the green padlock, don't enter your credit card number" but then what if the person sees the weaker symbol? You could say "go ahead" in which case they will go ahead all of the time or you could say "only go ahead under these additional circumstances" , what would they be?
jlgreco 13y ago
This is a great idea, but I wonder how far you can go with it. Could you also change the lock icon when larger more secure keys are used? Could you perhaps have the lock icon change color between a continuum of red to green (or better, black to white, or something accessible to colorblind people) depending on how the site is set up?
- dllthomas 13y ago
  Probably it should be a rolling standard, based on current best-practices.
  - jlgreco 13y ago
    I was thinking it would be up to the browser vendor to decide how to rate things, but if there were a more formal system that would be great I think.
    - dllthomas 13y ago
      Oh, I'd just meant "standard" in the "something against which you measure things" sense, and had been thinking per-browser, but I agree that some industry-wide coordination would be fantastic, if done right. Probably an industry-wide lower bound, with individual browsers allowed to require more security for a given marking, would be best.
- Skalman 13y ago
  Assuming you're sarcastic, but don't you think it's right to punish sites that don't use the best encryption strategies? I'd support three stages: 1) no encryption, 2) some/partial encryption, 3) "perfect" encryption. For the partial encryption, the browser would provide an explanation of exactly how it could be compromised. For the case where the encrypted version does not have perfect forward secrecy, it could explain that if the server is compromised, this session can also be decrypted. I don't think browsers should cover the banks' asses here. Edit (since I can't reply deeper): I thought you were being sarcastic since I consider a gradient to be a really horrible idea. I'd want something where the browser tells me something. I don't want to wonder whether the new browser version changed the gradients slightly or a site improved its encryption strategy. Clear symbols and language is a must.
  - jlgreco 13y ago
    I'm not being sarcastic, I think this is a good idea. I probably came off wrong because half-way through writing my comment I actually changed my mind, I guess my tone leaked through though.
- roc 13y ago
  People are not going to pay attention to a color-coded internet-weather-report sort of icon. But maybe if you switched the iconography/expectation: use a 'person' icon, instead of the lock, for vanilla SSL. It would indicate you have verified the server's identity -- which is not nothing -- but you can reserve the lock icon for forward-secure servers.
  - jlgreco 13y ago
    The problem of getting users who don't care to care is probably unsolvable without destroying usability. I think providing information nicely to people who care about it is the next best thing to shoot for.
    - roc 13y ago
      I don't think it's about users not caring at all. It's more about the limit to which they can add yet-another nuanced technology/security concern to their life and work and then keep up with it as times change. [1] We've got a question of granularity [2] and rather than make a professional value judgment in the average user's best interests [3], the proposal is trying to represent the entire scale and then expect the user to educate themselves about what the scale means, compare that to their environment needs, etc. [1] How long ago was it, we were simply railing against insufficient key sizes or improper certificate validation? Anyone who 'learned' up to that day's wisdom would have to continually update their knowledge along with the rest of us to be able to make informed decisions on which colors were 'safe' for which uses. [2] 'how secure' on a scale from 'unsecure' to 'SSL' to 'perfect forward secrecy' [3] drawing a line on the scale, to the left of which is not secure and to the right of which is secure. And, when 'less-secure' options prevent valuable information that isn't necessarily 'security' (e.g. identity validation) using a clear method of distinguishing that.
tptacek 13y ago
People barely pay attention to the lock icon. Why would color-coding the lock make a difference?
- rhizome 13y ago
  Because they can learn.
  - tptacek 13y ago
    That's what the people selling EV certs said. But EV certs have been a failure too, and they had a much louder UI. And at least EV certs were backed by a concept that people could understand. It's unreasonable to expect people outside of tech to understand "forward secrecy".
    - jessaustin 13y ago
      It is at least possible that EV certs have seen limited uptake because people understand too much about them. After all, they are the same CA "sure you can trust us" scam that we've always had, except with more rent-seeking. Some users and/or site operators might have been influenced e.g. by EV certs' unsavory association with Comodo.
      - tptacek 13y ago
        It is extremely unlikely that mass-market adoption of EV certificates has anything to do with the inside baseball of CA politics.
        jessaustin 13y ago
        So strike my last sentence. EV certs are still more onerous for site operators in terms of price and process than "normal" certs. They don't offer a credible increase in security or decrease in liability for anyone. Those facts suffice to explain the paucity of their mass-market adoption.
    - 13y ago
schtev 13y ago
Or just throw away the lock entirely, given that Google is in bed with the NSA.
- mpyne 13y ago
  Google is the only major player even employing perfect forward secrecy; hardly a case of a company trying to get extra-cozy with the NSA.
  - yk 13y ago
    Perfect forward secrecy would prevent some attacks against Google, as does certificate pinning in Chrome. But if the NSA got somehow Google's secret key, they can still MITM a SSL connection. It just means, that they actually need Google's secret key, instead of using a CA under their control. ( And they need this key before they can MITM any connection.) And the entire secure connection stuff is broken, if the NSA just obtains a FISA warrant for your GMail account. ( Or compromises the Google servers directly.)
    - commandar 13y ago
      >But if the NSA got somehow Google's secret key, they can still MITM a SSL connection. Security isn't my field at all, but I'd gotten the impression from HN that PFS is meant to protect against just this scenario. Am I mistaken?
      - bradleyjg 13y ago
        What PFS will protect against in this scanario is decrypting SSL sessions whose cyphertexts were captured before the attacker had access to the private key. It doesn't protect against (any) man-in-the-middle attacks.
        daeken 13y ago
        Before or after they have access to the private key, so long as an active MITM is not performed. In essence, PFS makes it such that no matter what information you have about the server's configuration, passive sniffing of data is not enough to compromise a connection's confidentiality.
inopinatus 13y ago
How about a big red nose next to the padlock?
andrewflnr 13y ago
I vote for having a rope tied in a knot as the icon: still sort of secure, just less so.
rdl 13y ago
Maybe, but in the long run the positive change would be by changing defaults everywhere, and then eventually throwing warnings for non-ephemeral SSL in the browser.

jiggy2011 13y ago

How do you explain that to people though? It's simple enough to say "if you don't see the green padlock, don't enter your credit card number" but then what if the person sees the weaker symbol? You could say "go ahead" in which case they will go ahead all of the time or you could say "only go ahead under these additional circumstances" , what would they be?

jlgreco 13y ago

This is a great idea, but I wonder how far you can go with it. Could you also change the lock icon when larger more secure keys are used? Could you perhaps have the lock icon change color between a continuum of red to green (or better, black to white, or something accessible to colorblind people) depending on how the site is set up?

dllthomas 13y ago
Probably it should be a rolling standard, based on current best-practices.
- jlgreco 13y ago
  I was thinking it would be up to the browser vendor to decide how to rate things, but if there were a more formal system that would be great I think.
  - dllthomas 13y ago
    Oh, I'd just meant "standard" in the "something against which you measure things" sense, and had been thinking per-browser, but I agree that some industry-wide coordination would be fantastic, if done right. Probably an industry-wide lower bound, with individual browsers allowed to require more security for a given marking, would be best.
Skalman 13y ago
Assuming you're sarcastic, but don't you think it's right to punish sites that don't use the best encryption strategies? I'd support three stages: 1) no encryption, 2) some/partial encryption, 3) "perfect" encryption. For the partial encryption, the browser would provide an explanation of exactly how it could be compromised. For the case where the encrypted version does not have perfect forward secrecy, it could explain that if the server is compromised, this session can also be decrypted. I don't think browsers should cover the banks' asses here. Edit (since I can't reply deeper): I thought you were being sarcastic since I consider a gradient to be a really horrible idea. I'd want something where the browser tells me something. I don't want to wonder whether the new browser version changed the gradients slightly or a site improved its encryption strategy. Clear symbols and language is a must.
- jlgreco 13y ago
  I'm not being sarcastic, I think this is a good idea. I probably came off wrong because half-way through writing my comment I actually changed my mind, I guess my tone leaked through though.
roc 13y ago
People are not going to pay attention to a color-coded internet-weather-report sort of icon. But maybe if you switched the iconography/expectation: use a 'person' icon, instead of the lock, for vanilla SSL. It would indicate you have verified the server's identity -- which is not nothing -- but you can reserve the lock icon for forward-secure servers.
- jlgreco 13y ago
  The problem of getting users who don't care to care is probably unsolvable without destroying usability. I think providing information nicely to people who care about it is the next best thing to shoot for.
  - roc 13y ago
    I don't think it's about users not caring at all. It's more about the limit to which they can add yet-another nuanced technology/security concern to their life and work and then keep up with it as times change. [1] We've got a question of granularity [2] and rather than make a professional value judgment in the average user's best interests [3], the proposal is trying to represent the entire scale and then expect the user to educate themselves about what the scale means, compare that to their environment needs, etc. [1] How long ago was it, we were simply railing against insufficient key sizes or improper certificate validation? Anyone who 'learned' up to that day's wisdom would have to continually update their knowledge along with the rest of us to be able to make informed decisions on which colors were 'safe' for which uses. [2] 'how secure' on a scale from 'unsecure' to 'SSL' to 'perfect forward secrecy' [3] drawing a line on the scale, to the left of which is not secure and to the right of which is secure. And, when 'less-secure' options prevent valuable information that isn't necessarily 'security' (e.g. identity validation) using a clear method of distinguishing that.

tptacek 13y ago

People barely pay attention to the lock icon. Why would color-coding the lock make a difference?

rhizome 13y ago
Because they can learn.
- tptacek 13y ago
  That's what the people selling EV certs said. But EV certs have been a failure too, and they had a much louder UI. And at least EV certs were backed by a concept that people could understand. It's unreasonable to expect people outside of tech to understand "forward secrecy".
  - jessaustin 13y ago
    It is at least possible that EV certs have seen limited uptake because people understand too much about them. After all, they are the same CA "sure you can trust us" scam that we've always had, except with more rent-seeking. Some users and/or site operators might have been influenced e.g. by EV certs' unsavory association with Comodo.
    - tptacek 13y ago
      It is extremely unlikely that mass-market adoption of EV certificates has anything to do with the inside baseball of CA politics.
      - jessaustin 13y ago
        So strike my last sentence. EV certs are still more onerous for site operators in terms of price and process than "normal" certs. They don't offer a credible increase in security or decrease in liability for anyone. Those facts suffice to explain the paucity of their mass-market adoption.
  - 13y ago

schtev 13y ago

Or just throw away the lock entirely, given that Google is in bed with the NSA.

mpyne 13y ago
Google is the only major player even employing perfect forward secrecy; hardly a case of a company trying to get extra-cozy with the NSA.
- yk 13y ago
  Perfect forward secrecy would prevent some attacks against Google, as does certificate pinning in Chrome. But if the NSA got somehow Google's secret key, they can still MITM a SSL connection. It just means, that they actually need Google's secret key, instead of using a CA under their control. ( And they need this key before they can MITM any connection.) And the entire secure connection stuff is broken, if the NSA just obtains a FISA warrant for your GMail account. ( Or compromises the Google servers directly.)
  - commandar 13y ago
    >But if the NSA got somehow Google's secret key, they can still MITM a SSL connection. Security isn't my field at all, but I'd gotten the impression from HN that PFS is meant to protect against just this scenario. Am I mistaken?
    - bradleyjg 13y ago
      What PFS will protect against in this scanario is decrypting SSL sessions whose cyphertexts were captured before the attacker had access to the private key. It doesn't protect against (any) man-in-the-middle attacks.
      - daeken 13y ago
        Before or after they have access to the private key, so long as an active MITM is not performed. In essence, PFS makes it such that no matter what information you have about the server's configuration, passive sniffing of data is not enough to compromise a connection's confidentiality.

inopinatus 13y ago

How about a big red nose next to the padlock?

andrewflnr 13y ago

I vote for having a rope tied in a knot as the icon: still sort of secure, just less so.

rdl 13y ago

Maybe, but in the long run the positive change would be by changing defaults everywhere, and then eventually throwing warnings for non-ephemeral SSL in the browser.