12 ms·

I think the history and architecture lesson here is clear: conflating privacy with trust/identity was a huge mistake. We could've had a mostly encrypted Inte

I think the history and architecture lesson here is clear: conflating privacy with trust/identity was a huge mistake. We could've had a mostly encrypted Internet a long time ago if encryption and privacy were not hitched to a commercial identity certificate with crappy maintenance tools. I hope security architects going forward heed this lesson.

nkozyra 9y ago
Great point, although I think the conflation is a little more dangerous. For many users, it's privacy=safety.
tptacek 9y ago
This is a very common complaint, and it's not valid. You cannot have privacy without some form of trust or identity. Network cryptography doesn't work that way. We have to assume the adversary controls the network, and so can manipulate any cryptographic handshake they see. The "identity" in TLS exists principally in order to prevent network adversaries from substituting their own keys for those of your intended peer.
- ynniv 9y ago
  I think that's only true if your trust system recognizes the attacking key as valid for the destination. DV seems to prevent that, absent typo squatting.
  - dogecoinbase 9y ago
    tptacek is referring to the chain of trust that's used to validate that the issuer for a DV certificate is someone we trust to perform DV.
  - tptacek 9y ago
    I'm not arguing that we have the optimal trust system now. I'm saying that the argument that we should have started with "privacy" for everyone and made trust optional is invalid. A different key infrastructure may very well have been better than the X.509 PKI! But not having any identity in the system is an unrealistic goal.
  - wbond 9y ago
    Whenever dealing with financial websites, I am always extremely suspicious of a website that does not have an EV certificate because of the added level of scruitiny applied to such certs. The number of mis-issued DV certs, and typos means that it would be relatively easy to enter banking credentials to a well-executed phishing site. It is going to be a lot harder to get an EV cert issued to paypa1.com with “PayPal, Inc. [US]” as the organization. The only website that I regularly have anxiousness about entering my credentials on are Google properties. Since email can be used to reset pretty much anything, Google is one of the most important set of credentials to prevent falling into the wrong hands. Unfortunately they don’t seem to care about EV certs. Additionally, app-based OAuth screens with web login prompts regularly give me pause. I don’t like not being able to see the URL and certificate information.
    - tracker1 9y ago
      It's funny, but this is where having a password manager really saves me... if I don't have a login for a site I use often, I'll really scrutinize it... sometimes login urls change, but not very often.
- drostie 9y ago
  That's 100% accurate but the parent post is clearly about EV certs attempting to provide added trust/identity beyond what's needed for the privacy provided by TLS, and it's skeptical that that's happening. A more-SSH-like approach would be for browsers to identify PSL-level domains with simple site names, which can be done by-hand for the Alexa top 500 if nothing else; so "https://docs.google.com/whatever" https://docs.google.com/whatever" maps to a green "Google docs> whatever" in your URL bar; click to reveal the full URL. The idea is that a local store for this mapping is distributed across all of the browsers out there, so by default you get a yellow arrow on `-> https://idontknowthisdomain.example/` https://idontknowthisdomain.example/` and perhaps as HTTP goes south we get a red one on `-> http://thisdomainneither.example/` http://thisdomainneither.example/`. But you can right click that yellow arrow and it asks "Do you trust the following domain?" with a "Name: ____" box to submit your own name. After that, this domain has been white-listed for you to have the given name, just as in HTTPS. Possibly you can even have the page itself suggest the name via a meta tag. The important point is that the user has to say that they trust this domain to have that common-name, before they see it pop up in green. From there, the browsers can do what they already do best: phone home. If you get millions of different users suggesting the same official name for a web site, it's more reasonable to automatically add them so that more than just the instantaneous Alexa Top 500 is covered. You still rely on the core certs to provide privacy, but people who visit a phishing site now see by default either a yellow or red arrow where they are accustomed to seeing a green one that they either set up themselves or someone else set up for them.
  - gruez 9y ago
    >From there, the browsers can do what they already do best: phone home. If you get millions of different users suggesting the same official name for a web site, it's more reasonable to automatically add them so that more than just the instantaneous Alexa Top 500 is covered. What about sybil attacks?
    - deleted 9y ago
      [deleted]
    - deleted 9y ago
      [deleted]
- tedunangst 9y ago
  Key continuity gets you pretty far, though. Knowing I'm talking to the same paypal as I was yesterday is about as, if not more, comforting as having somebody else assert "this is paypal".
  - mdpopescu 9y ago
    True. I have first encountered this idea many years ago, with the Kong program [1]. "Unlike most digital signature programs, this one has no concept of "true names". It makes no attempt to determine that the Bob you are talking to is the "real" Bob. It merely ensures that it is the same Bob." [1] http://echeque.com/Kong/Kong.htm http://echeque.com/Kong/Kong.htm
  - jasode 9y ago
    >Key continuity gets you pretty far, But that implies that some time in the past, you had a "first contact" with the real Paypal. You then need something somewhere that helps validate that initial trust. And let's say a computer already made first contact with paypal.com and bankofamerica.com, what happens when the user needs to format the harddrive or gets a brand new smartphone? Do they export their previous successful handshakes to a flash card and import them into their new device to maintain key continuity? Or is it easier to use an entity (CAs or something similar) to help establish indentity+trust?
    - rocqua 9y ago
      There is no either or. Key continuity combined with CAs is better than either alone. CAs for the first use, and key continuity for most of the rest. Another interesting option is called triangulation IIRC. The idea is to randomly query some other clients for their key-continuity info on first use.
      - jasode 9y ago
        >There is no either or. Right, but it seemed like tedunangst's continuity suggestion was an answer to tptacek's "You cannot have privacy without some form of trust or identity." Since continuity doesn't work for 1st contact, it still doesn't solve the fundamental trust issue. Based on the thread's context about the value or worthlessness of CAs... If you have to still use CAs for 1% of the key handshakes, "key continuity" seems like a tangent to the topic.
- tbrownaw 9y ago
  This is a very common complaint, and it's not valid. You cannot have privacy without some form of trust or identity. There's no reason that "Only $KEY can read this" and "$KEY belongs to $READ_WORLD_ENTITY" have to be tightly coupled. Just because you need [the network operator to think you have] some form of the latter, does not in any way mean that the former is "not valid" unless it has one particular form of it baked in. Tight coupling is evil (ref. dependency injection), and complaining about it is not in any way not valid.
- steventhedev 9y ago
  Why do we need to assume the adversary controls the network? We've seen real examples of such attacks on networks, using methods like cable splicing, passive wifi listening, etc. While there are alternatives to such attacks, active attacks require a greater investment by the attacker, and in some cases aren't practically feasible without being detected by the legitimate network operator.
  - gjjrfcbugxbhf 9y ago
    After the Snowden releases it is safe to say an adversary does control the network.
    - steventhedev 9y ago
      Any given state actor will have full control over some networks. It's fair to say that any given network is fully controlled by at least one state actor, possibly more. It also stands to reason that each state actor has many more networks they can passively listen to. [EDIT: clarity] Ultimately, if your threat model is to protect against the actions of a state actor who likely does not have active control over your network, but might be able to passively listen, then ubiquitous encryption helps a lot with defense in depth. A more mundane case is free wifi at an airport. Someone can set up a hotspot with the same SSID and act as a MitM, but it's not undetectable. Here, encrypting application traffic is just one solution, and not necessarily the best one, but you shouldn't be relying on only one layer of protection.
  - willstrafach 9y ago
    > active attacks require a greater investment by the attacker Anyone connected to the network you are connected to has the ability to route your traffic through themselves and sniff/manipulate it.
- wereHamster 9y ago
  > You cannot have privacy without some form of trust or identity. For privacy the only trust you need is into cryptography.
siliconc0w 9y ago
Browsers should have some sort of non-binary 'trust' score that looks at things like: * how many users have been here before * how 'new' is the site * how much does it look like other popular sites or sites the user has visited (perceptual hash) * how close is it's name to a popular site (levenshtein distance) * how did the user get here (clicked a link vs clicked a bookmark) * does it have form fields * does it appear to ask for credentials (OCR rendered page for 'Login', 'Username',or 'Password') This score should be what gets you the pretty green padlock - otherwise you should just get a dull grey "Private Connection" label. I imagine it's possible to evade some or all of these but it increases the difficulty and cost of shenanigans. We often get tripped up where for security application we like some sort of mathematical certainty we're protected when 'pretty good' is still better than nothing.
- matt4077 9y ago
  I think browser vendors may be hesitant to implement anything but a clearly defined protocol, because almost by definition a probabilistic model will result in them occasionally vouching for the wrong sites. Even if they could probably exclude legal liability, it may create PR headaches. As a small fish in the big pond that is the www, I'm also wary of any solution that may end up giving the handful of established behemoths an advantage that smaller competitors cannot at least in theory also get (except by growing to similar size). Right now, there's a process that establishes a "good enough" level: EV certificates are within the reach of even small websites, and with my identity being known and proven, I'd argue that they actually track pretty closely to the actual "truth" of the respective trust-worthiness.
  - siliconc0w 9y ago
    They vouch for bad sites all the time already - that is what the article is arguing. If a site pops into existence maybe it shouldn't be trusted immediately. Trust has to be earned and this is a protocol to 'earn trust'. The goal is to disambiguate 'trust' with 'encrypted connection'.
    - 9y ago
donpdonp 9y ago
Agreed. I want encryption not verified-identity from SSL. Self-signed certs provide encryption - browser makers didn't let that happen and created a $$$ monopoly in CAs. It wasnt until the CA list became so obviuously broken ('approved' CAs issuing bogus google.com certs for example) that letsencrypt became conceivable. I'll use the cert-ID and my own mechanism to validate the cert-ID, like a name system. a Distributed name system even.
snakeanus 9y ago
I wish that the tor and i2p style (hashes of public keys/the public keys as) addresses were the way we did encryption and verified integrity on the internet.
gerdesj 9y ago
The real snag is the way that SSL/TLS is marketed. In the post is a link to a belting tweet by a Scott Hanselman: "HTTPS & SSL doesn't mean "trust this." It means "this is private." You may be having a private conversation with Satan." TLS (nee SSL) was conceived a long time ago (it's about a 10th of the age of my house but in internet terms a good while back) and is now ubiquitous. The trouble is that end users int al. do not really understand what it really means. It really doesn't help that Chrome/Chromium and Firefox at least are making it harder and harder to actually view a SSL cert from a website. The Google mob are making it almost bloody impossible for those not familiar with dev tools - rubbish.
- ploxiln 9y ago
  I think the real take-away here is that there is just no substitute for looking at the URL bar to see the domain. HTTPS means that the url bar is not lying, but you still have to look there and see if it's the correct entity. EV certs are more of the same - you still have to look up at that URL bar and see the organization name. All of us who know how to trust websites, do it by looking at the domain. We don't remember what sites have an EV cert. It doesn't matter, the standard procedure always works: check https, check domain, done. No other solution works reliably, at the scale of the web. Any other solution ends up adding complication. Doing this the right way really isn't hard, people just need one half-hour class, in their entire life, to enable them to reasonably safely use the web.

nkozyra 9y ago

Great point, although I think the conflation is a little more dangerous. For many users, it's privacy=safety.

tptacek 9y ago

This is a very common complaint, and it's not valid. You cannot have privacy without some form of trust or identity. Network cryptography doesn't work that way. We have to assume the adversary controls the network, and so can manipulate any cryptographic handshake they see. The "identity" in TLS exists principally in order to prevent network adversaries from substituting their own keys for those of your intended peer.

ynniv 9y ago
I think that's only true if your trust system recognizes the attacking key as valid for the destination. DV seems to prevent that, absent typo squatting.
- dogecoinbase 9y ago
  tptacek is referring to the chain of trust that's used to validate that the issuer for a DV certificate is someone we trust to perform DV.
- tptacek 9y ago
  I'm not arguing that we have the optimal trust system now. I'm saying that the argument that we should have started with "privacy" for everyone and made trust optional is invalid. A different key infrastructure may very well have been better than the X.509 PKI! But not having any identity in the system is an unrealistic goal.
- wbond 9y ago
  Whenever dealing with financial websites, I am always extremely suspicious of a website that does not have an EV certificate because of the added level of scruitiny applied to such certs. The number of mis-issued DV certs, and typos means that it would be relatively easy to enter banking credentials to a well-executed phishing site. It is going to be a lot harder to get an EV cert issued to paypa1.com with “PayPal, Inc. [US]” as the organization. The only website that I regularly have anxiousness about entering my credentials on are Google properties. Since email can be used to reset pretty much anything, Google is one of the most important set of credentials to prevent falling into the wrong hands. Unfortunately they don’t seem to care about EV certs. Additionally, app-based OAuth screens with web login prompts regularly give me pause. I don’t like not being able to see the URL and certificate information.
  - tracker1 9y ago
    It's funny, but this is where having a password manager really saves me... if I don't have a login for a site I use often, I'll really scrutinize it... sometimes login urls change, but not very often.
drostie 9y ago
That's 100% accurate but the parent post is clearly about EV certs attempting to provide added trust/identity beyond what's needed for the privacy provided by TLS, and it's skeptical that that's happening. A more-SSH-like approach would be for browsers to identify PSL-level domains with simple site names, which can be done by-hand for the Alexa top 500 if nothing else; so "https://docs.google.com/whatever" https://docs.google.com/whatever" maps to a green "Google docs> whatever" in your URL bar; click to reveal the full URL. The idea is that a local store for this mapping is distributed across all of the browsers out there, so by default you get a yellow arrow on `-> https://idontknowthisdomain.example/` https://idontknowthisdomain.example/` and perhaps as HTTP goes south we get a red one on `-> http://thisdomainneither.example/` http://thisdomainneither.example/`. But you can right click that yellow arrow and it asks "Do you trust the following domain?" with a "Name: ____" box to submit your own name. After that, this domain has been white-listed for you to have the given name, just as in HTTPS. Possibly you can even have the page itself suggest the name via a meta tag. The important point is that the user has to say that they trust this domain to have that common-name, before they see it pop up in green. From there, the browsers can do what they already do best: phone home. If you get millions of different users suggesting the same official name for a web site, it's more reasonable to automatically add them so that more than just the instantaneous Alexa Top 500 is covered. You still rely on the core certs to provide privacy, but people who visit a phishing site now see by default either a yellow or red arrow where they are accustomed to seeing a green one that they either set up themselves or someone else set up for them.
- gruez 9y ago
  >From there, the browsers can do what they already do best: phone home. If you get millions of different users suggesting the same official name for a web site, it's more reasonable to automatically add them so that more than just the instantaneous Alexa Top 500 is covered. What about sybil attacks?
  - deleted 9y ago
    [deleted]
  - deleted 9y ago
    [deleted]
tedunangst 9y ago
Key continuity gets you pretty far, though. Knowing I'm talking to the same paypal as I was yesterday is about as, if not more, comforting as having somebody else assert "this is paypal".
- mdpopescu 9y ago
  True. I have first encountered this idea many years ago, with the Kong program [1]. "Unlike most digital signature programs, this one has no concept of "true names". It makes no attempt to determine that the Bob you are talking to is the "real" Bob. It merely ensures that it is the same Bob." [1] http://echeque.com/Kong/Kong.htm http://echeque.com/Kong/Kong.htm
- jasode 9y ago
  >Key continuity gets you pretty far, But that implies that some time in the past, you had a "first contact" with the real Paypal. You then need something somewhere that helps validate that initial trust. And let's say a computer already made first contact with paypal.com and bankofamerica.com, what happens when the user needs to format the harddrive or gets a brand new smartphone? Do they export their previous successful handshakes to a flash card and import them into their new device to maintain key continuity? Or is it easier to use an entity (CAs or something similar) to help establish indentity+trust?
  - rocqua 9y ago
    There is no either or. Key continuity combined with CAs is better than either alone. CAs for the first use, and key continuity for most of the rest. Another interesting option is called triangulation IIRC. The idea is to randomly query some other clients for their key-continuity info on first use.
    - jasode 9y ago
      >There is no either or. Right, but it seemed like tedunangst's continuity suggestion was an answer to tptacek's "You cannot have privacy without some form of trust or identity." Since continuity doesn't work for 1st contact, it still doesn't solve the fundamental trust issue. Based on the thread's context about the value or worthlessness of CAs... If you have to still use CAs for 1% of the key handshakes, "key continuity" seems like a tangent to the topic.
tbrownaw 9y ago
This is a very common complaint, and it's not valid. You cannot have privacy without some form of trust or identity. There's no reason that "Only $KEY can read this" and "$KEY belongs to $READ_WORLD_ENTITY" have to be tightly coupled. Just because you need [the network operator to think you have] some form of the latter, does not in any way mean that the former is "not valid" unless it has one particular form of it baked in. Tight coupling is evil (ref. dependency injection), and complaining about it is not in any way not valid.
steventhedev 9y ago
Why do we need to assume the adversary controls the network? We've seen real examples of such attacks on networks, using methods like cable splicing, passive wifi listening, etc. While there are alternatives to such attacks, active attacks require a greater investment by the attacker, and in some cases aren't practically feasible without being detected by the legitimate network operator.
- gjjrfcbugxbhf 9y ago
  After the Snowden releases it is safe to say an adversary does control the network.
  - steventhedev 9y ago
    Any given state actor will have full control over some networks. It's fair to say that any given network is fully controlled by at least one state actor, possibly more. It also stands to reason that each state actor has many more networks they can passively listen to. [EDIT: clarity] Ultimately, if your threat model is to protect against the actions of a state actor who likely does not have active control over your network, but might be able to passively listen, then ubiquitous encryption helps a lot with defense in depth. A more mundane case is free wifi at an airport. Someone can set up a hotspot with the same SSID and act as a MitM, but it's not undetectable. Here, encrypting application traffic is just one solution, and not necessarily the best one, but you shouldn't be relying on only one layer of protection.
- willstrafach 9y ago
  > active attacks require a greater investment by the attacker Anyone connected to the network you are connected to has the ability to route your traffic through themselves and sniff/manipulate it.
wereHamster 9y ago
> You cannot have privacy without some form of trust or identity. For privacy the only trust you need is into cryptography.

siliconc0w 9y ago

Browsers should have some sort of non-binary 'trust' score that looks at things like: * how many users have been here before * how 'new' is the site * how much does it look like other popular sites or sites the user has visited (perceptual hash) * how close is it's name to a popular site (levenshtein distance) * how did the user get here (clicked a link vs clicked a bookmark) * does it have form fields * does it appear to ask for credentials (OCR rendered page for 'Login', 'Username',or 'Password') This score should be what gets you the pretty green padlock - otherwise you should just get a dull grey "Private Connection" label. I imagine it's possible to evade some or all of these but it increases the difficulty and cost of shenanigans. We often get tripped up where for security application we like some sort of mathematical certainty we're protected when 'pretty good' is still better than nothing.

matt4077 9y ago
I think browser vendors may be hesitant to implement anything but a clearly defined protocol, because almost by definition a probabilistic model will result in them occasionally vouching for the wrong sites. Even if they could probably exclude legal liability, it may create PR headaches. As a small fish in the big pond that is the www, I'm also wary of any solution that may end up giving the handful of established behemoths an advantage that smaller competitors cannot at least in theory also get (except by growing to similar size). Right now, there's a process that establishes a "good enough" level: EV certificates are within the reach of even small websites, and with my identity being known and proven, I'd argue that they actually track pretty closely to the actual "truth" of the respective trust-worthiness.
- siliconc0w 9y ago
  They vouch for bad sites all the time already - that is what the article is arguing. If a site pops into existence maybe it shouldn't be trusted immediately. Trust has to be earned and this is a protocol to 'earn trust'. The goal is to disambiguate 'trust' with 'encrypted connection'.
  - 9y ago

donpdonp 9y ago

Agreed. I want encryption not verified-identity from SSL. Self-signed certs provide encryption - browser makers didn't let that happen and created a $$$ monopoly in CAs. It wasnt until the CA list became so obviuously broken ('approved' CAs issuing bogus google.com certs for example) that letsencrypt became conceivable. I'll use the cert-ID and my own mechanism to validate the cert-ID, like a name system. a Distributed name system even.

snakeanus 9y ago

I wish that the tor and i2p style (hashes of public keys/the public keys as) addresses were the way we did encryption and verified integrity on the internet.

gerdesj 9y ago

The real snag is the way that SSL/TLS is marketed. In the post is a link to a belting tweet by a Scott Hanselman: "HTTPS & SSL doesn't mean "trust this." It means "this is private." You may be having a private conversation with Satan." TLS (nee SSL) was conceived a long time ago (it's about a 10th of the age of my house but in internet terms a good while back) and is now ubiquitous. The trouble is that end users int al. do not really understand what it really means. It really doesn't help that Chrome/Chromium and Firefox at least are making it harder and harder to actually view a SSL cert from a website. The Google mob are making it almost bloody impossible for those not familiar with dev tools - rubbish.

ploxiln 9y ago
I think the real take-away here is that there is just no substitute for looking at the URL bar to see the domain. HTTPS means that the url bar is not lying, but you still have to look there and see if it's the correct entity. EV certs are more of the same - you still have to look up at that URL bar and see the organization name. All of us who know how to trust websites, do it by looking at the domain. We don't remember what sites have an EV cert. It doesn't matter, the standard procedure always works: check https, check domain, done. No other solution works reliably, at the scale of the web. Any other solution ends up adding complication. Doing this the right way really isn't hard, people just need one half-hour class, in their entire life, to enable them to reasonably safely use the web.