7 ms·

Fix TLS – Let’s Get Rid of Certificates

dan1234 10y ago
So, essentially the same way SSH works? The main problem I'd see is training users to get that initial trust phase correct. Too many wouldn't try to parse the info given and just click Trust regardless (or run away from every site with the warning).
- icebraining 10y ago
  The same way, except SSH is generally used for a small number of hosts that the user itself (or their organisation) controls, so there's some chance for out-of-band verification.
- dspillett 10y ago
  > So, essentially the same way SSH works? Not if you are doing SSH right... That "fingerprint validation" message you get the first time you connection to a SSH host: you should be verifying that against a copy received through another (preferably secure of course) channel, not just blindly trusting the first fingerprint you are shown.
NeutronBoy 10y ago
Nice writeup - good to see a solution proposed, rather than the same complaints about 'how TLS is broken'! That said, the key flaw that's raised at the start of the article (how do you know that amazon.de is Amazon) is not really solved with this solution. You still need a trusted third party to bootstrap that first visit.
- mborch 10y ago
  For most people that's currently Google due to search-based location bar.
icebraining 10y ago
1) So I boot my new phone, connect to some coffeeshop's wi-fi and navigate to some HTTPS site. The coffeeshop's captive portal intercepts my request to show me a TOS page, sending me their public key instead. Now my browser has that key remembered for that domain, and will error when I visit the real site. 2) Key rollovers are accepted silently if signed with the previous key. So an attacker who steals the key can sign their valid ones forever, right? If the server can invalidate previous keys to reduce that risk, what happens when the attacker uses that feature themselves against the actual site owners? 3) How is TOFU better than previous proposals like Perspectives and Convergence?
- chillaxtian 10y ago
  > 1) So I boot my new phone, connect to some coffeeshop's wi-fi and navigate to some HTTPS site. The coffeeshop's captive portal intercepts my request to show me a TOS page, sending me their public key instead. Now my browser has that key remembered for that domain, and will error when I visit the real site. yeah.. this brings us back to basically the same setup as before. your device needs to reach out to some 'trusted party' to ask it whether it should warn you about the key. how does your device connect securely to this trusted party, so someone can't mitm the trust question? ship the trusted parties key on the device. .. sound familiar?
  - Qantourisc 10y ago
    Almost, but now you only have to trust one third party, not 189 (/etc/ssl/certs).
    - rocqua 10y ago
      There needn't be a lot of difference, if that single trusted party still signs a lot of other CA certificates. You don't just need to trust the root certificates intsalled, you need to trust all signed CA certificates those root certificates installed (except for public key pinning, which will ignore installed root certificates).
  - derefr 10y ago
jstewartmobile 10y ago
It would be progress for the savvy and regression for everyone else, but I still like his thinking here even if it's ultimately a mistake.
- icebraining 10y ago
  If the savvy want this they can already have it, it's just a matter of removing the certs from the browser's CA store.
  - jstewartmobile 10y ago
    He added a few flourishes, like network insights, pre-installed certs, and a signature in the header for key rotation. Might be fun to usability test that scenario in a VM or something just to see how it works in practice.
mholt 10y ago
Having spent a few years dabbling in TLS stuff recently... I have some comments. This article is really about PKI more than TLS, and what it means to be a user's agent ("user agent"). Forgive my critical tone in advance, it's just that proposals like this need to go through the wringer... > you are supposed to be certain that you are communicating with the website you intended to visit. the green padlock in front of the URL in your browser tells you TLS is securing the connection. But this reasoning is wrong. No, it's not. It's correct to reason that the green lock (as implemented by most modern browsers) indicates a secure connection to the site in the URL bar. Now, whether that site is behaving virtuously... is a different matter, and not one that TLS is designed to solve. It also doesn't mean TLS is broken. (TLS is quite good, especially the emerging 1.3 standard. Qualms with TLS usually end up being about PKI, which is the best thing we've got widely deployed right now, whether you like it or not.) "Intended to visit" -- when we look at the browser as the role of the user agent, or in other words, a program that is supposed to act helpfully on behalf of the user -- the browser infers intent from what the user tells it to do. If you have a private chauffeur and you tell him to take you to such-and-such place, he will go there, even if you intended to go to such-another place. Oops? Maybe agents who know you really well could double-check with you if they think you meant something else, but do you really want your browser to know that much about you? > The real solution: get rid of certicificates This is ridiculous. Certificates make possible the cryptographic exchanges that guarantee confidentiality, host (and client) authenticity, and data integrity. Don't throw away the single most valuable component of modern Web security. > Being able to tell that we are visiting the same website as before allows us to establish a trust relationship with that website over time. With every positive interaction, our trust increases (and with every bad experience, our trust drops). We don’t need the website’s name for that. This isn't about TLS, this is now about PKI and trust model issues. Yes, there are various trust models and each have advantages and disadvantages. We went with PKI for the wider Internet because it fits the mold best when connecting machines to other machines at scale. In contrast, WoT and other models (including TOFU) work better in small groups of people or machines in semi-controlled environments (e.g. TOFU is manageable with your small-medium-sized fleet of servers).
- iancarroll 10y ago
  Agreed. Straight TOFU without CAs is a bad idea usability wise; we're still struggling to get the UI down for padlocks... But when you combine TOFU and CAs, well, you get something like HPKP, which is a good middle ground, I think.
vbernat 10y ago
Putting keys from popular websites would increase centralization: content will be moved to Facebook and the likes to avoid the warning. This TOFU thing could be useful with self-signed certificates (like those shipped in servers' BMC).
- icebraining 10y ago
  This TOFU thing could be useful with self-signed certificates (like those shipped in servers' BMC). But that's how it already works, at least traditionally (how don't know about Chrome): you connect to it, and the browser asks you if you want to make a permanent exception for that cert. Next time, it'll just connect.
  - vbernat 10y ago
    In Chrome, there is no such thing as a permanent exception. In Firefox, the permanent exception includes unexpected certificate change.
    - leni536 10y ago
      > In Firefox, the permanent exception includes unexpected certificate change. I didn't know this. This is horrible and does not make any sense.
lend000 10y ago
No matter what, you have to trust someone, and any method that requires first-time click through every time on every new website is bound to exhaust users, resulting in them clicking through blindly. At least a certificate violation is a rare enough event, although as mentioned, it can potentially be corrupted by the CA. Regardless, you trust the browser implementation. A better solution might have browsers try to intelligently identify suspicious looking URL's (including URL's that start with a popular, external URL, like paypal.com.notpaypal.cc). As for the actual certificates themselves, perhaps this is a good application for a Blockchain technology, with certs being created by website owners and submitted to a Blockchain by a machine assigned to the DNS name that wants to create its cert. But in this case, we still require DNS which is built on trust... so perhaps DNS could also be put on a blockchain. How? I don't know. But until we figure that out, we have to rely on various organizations to provide trust.
- dchest 10y ago
  resulting in them clicking through blindly In the proposed scheme, they are ALWAYS clicking though blindly. There's no way for a user to know when he gets the original public key or someone else's. How is a user supposed to verify it, call the owners of the website and ask them to dictate their public key? This warning screen is thus just a security theater. The whole proposed "solution" is not a solution at all and doesn't work — the author could have saved a lot of time typing this blog post if they just listed threats that certificates are trying to solve on a piece of paper and put a check mark next to each if their proposed "solution" solves it.
lexman0 10y ago
I completely disagree with this. Public key pinning has some well known problems that make it very dangerous to implement at scale [1]. There are some very large problems that this introduces and does not solve: - How do kiosk machines now work? How can I trust any website when every use is first use? - What about https domains for images and scripts? Is the user supposed to trust each domain separately? - Assuming trusting a domain trusts all its other domains mentioned in its content-security-policy, how is this trust revoked for misuse? - Is the author suggesting that we retain all users of browsers everywhere? I believe that to be a herculean task. Certificates have their problems, but this is not a solution. I will not propose one here, because it is an extremely complicated problem that needs many separate parties working together to solve. [1] https://blog.qualys.com/ssllabs/2016/09/06/is-http-public-key-pinning-dead https://blog.qualys.com/ssllabs/2016/09/06/is-http-public-ke...
- __david__ 10y ago
  > How do kiosk machines now work? How can I trust any website when every use is first use? Should you ever really trust kiosk machines? They could easily be setup with MITM eavesdropping software. > What about https domains for images and scripts? Is the user supposed to trust each domain separately? Presumably there could be some sort of <meta> header that listed the public key fingerprint/IDs of any subdomains that the page was going to pull in. This would make the UX better. > Assuming trusting a domain trusts all its other domains mentioned in its content-security-policy, how is this trust revoked for misuse? AFAIK, revocation isn't very good even with the current CA infrastructure[1][2]. [1] https://news.netcraft.com/archives/2014/04/24/certificate-revocation-why-browsers-remain-affected-by-heartbleed.html https://news.netcraft.com/archives/2014/04/24/certificate-re... [2] https://www.maikel.pro/blog/current-state-certificate-revocation-crls-ocsp/ https://www.maikel.pro/blog/current-state-certificate-revoca...
  - lexman0 10y ago
    > Should you ever really trust kiosk machines? They could easily be setup with MITM eavesdropping software. I should have the choice. This doesn't even give me that. > Presumably there could be some sort of <meta> header that listed the public key fingerprint/IDs of any subdomains that the page was going to pull in. This would make the UX better. This would make the UX barely passable. If any of these domains change the content at all so the hash changes, how does it get updated? > AFAIK, revocation isn't very good even with the current CA infrastructure[1][2]. I completely agree with you, so lets not make it any worse.
chaz6 10y ago
RFC 6844 defines a DNS record (CAA) which supposedly allows you to restrict which CA's are allowed to issue a certificate for your domain. Of course, this is on the honor basis. https://tools.ietf.org/html/rfc6844 https://tools.ietf.org/html/rfc6844
- rocqua 10y ago
  That can be secured with DNS-Sec, leading to DANE. It is often suggested as either an addition or replacement for the CA system. However, this is basically the CA system in disguise. Instead of trusting CAs, we need to trust domain servers. Thing is, domain servers tend to be controlled by governments even more so than CAs. There are some other issues with the technical implementation of DNS-sec, though I do not recall them at this moment.
  - chaz6 10y ago
    I think ultimately you end up having to have a web of trust, but this assumes that the devices of the people in your web have not been compromised (backdoored apps and/or crypto libs).
    - rocqua 10y ago
      I think a system like CAs or DNS-sec, with hierarchical trust is a good base. However, we'd need to add certificate transparency and 'triangulation'. Certificate transparency is a centralized way to detect wrongly-issued certificates. Triangulation is a peer-to-peer way, where a client asks a few other clients what certificate they have. I like a DNS-based approach, because it ensures only one authority can authorize a key, though it has the issue of often being a state-controlled authority.
      - chaz6 10y ago
        I tend to like the DNS approach as it is supposedly non-commercial and non-state operated, but again you have to place your trust in a group of people you do not know (I have never met one of the root signers before), so you have no way to know if they or their equipment have been compromised by a state actor.
KentLatricia 10y ago
This article seems to miss the point that a website rarely serves content from a single domain. If it pulls content from 30 different domains, all TLS protected, would the user get 30 popups asking it to allow them each? The current TLS/PKI allows for much better UX, users would reject the proposed solution.
- philliphaydon 10y ago
  Someone suggested some sort of metadata that could be passed down to the browser to say this list of domains or such are valid. But if the website is hacked to have injected metadata put in then I kind of think that's ever worse than the current problem. It gives trust to a domain implicitly.
Johnny_Brahms 10y ago
Moxie had a talk called "SSL and the Future of Authenticity" at blackhat about an old project of his called Convergence. The talk is on youtube. https://en.wikipedia.org/wiki/Convergence_(SSL) https://en.wikipedia.org/wiki/Convergence_(SSL)
- deleted 10y ago
  [deleted]
- y7 10y ago
  It's a shame Convergence was discontinued. I think it was a good solution to the problem.
Aissen 10y ago
There are browser extensions to implement TOFU. Just use that if that's your thing, don't make the rest of us insecure please.
lsiebert 10y ago
key rotation and signing with the previous key doesn't work for credentials that are compromised. It also potentially fails for devices that miss a whole key rotation, which could happen for devices that aren't regularly connected to the internet but still need access for things like firmware upgrades.
lsiebert 10y ago
key rotation and signing with the previous key doesn't work for credentials that are compromised. It also potentially fails for devices that miss a whole key rotation, which could happen for devices that aren't regularly connected to the internet but still need access for things like firmware upgrades.
d_theorist 10y ago
The Netherlands is an 'evil government'?
- majewsky 10y ago
  Depends on perspective (although I guess that the US would've been a better example). There are many people who consider the Chinese government as much not evil as you do the government of Netherlands.
jlgaddis 10y ago
> ... a system where ... information about the domain being visited is displayed from various sources (e.g. Google, or known phishing domain databases like PhishTank) that have a global network picture and hence are in a unique position to tell very early on whether a certain domain is untrustworthy. So, a trusted third-party, then? To, you know, certify the site? Like... a Certification Authority, perhaps? > If this is the first time you are visiting this website, a warning message will appear. Your browser will provide some useful information about this site (see below) and ask you whether you want to continue and really visit this site. How's that going to work when visiting any of the majority of sites today that pull in resources from perhaps 20 or more different domains? Google Analytics, some other analytics, ads, all the trackers, ... On a whim, I just pulled up CNN's web site [0]. uBlock Origin reports a total of 21 domains. How is the average user supposed to know if zor.fyre.co is legitimate -- or a tracker or a phishing site or "evil Russian hackers" and shouldn't be trusted? There's a lot that's wrong with the current state of PKI on the web (too many CAs, questionable CAs, etc.) but that doesn't mean we should just throw it all out tomorrow. We're stuck with it -- at least until something better is devised and rolled out (which would take years!) -- so the best we can do is hope for continued incremental improvements, such as TLS 1.3. [0]: http://www.cnn.com/ http://www.cnn.com/
- rictic 10y ago
  I don't want a web where every time a user visits a new domain they see a scary interstitial warning that asks them to make a trust decision. We have too many centralizing forces already.
  - Crosseye_Jack 10y ago
    > I don't want a web where every time a user visits a new domain they see a scary interstitial warning that asks them to make a trust decision. I don't want it either as it easily trains users to click though it. User goes to new website: "Oh yeah I have to click allow <CLICK>"... User returns to site but its now being MITM'ed: "Oh I thought I had clicked allow. <CLICK>"... Even if the warning is something like "the public key for this site has changed, do you wish to continue?" The gen public will click continue. The problem is not designing a system us on hacker news can use, understand and keep us secure but its building a system that "non-technical" (Throw in generalisation about parents/grandparents not understanding the interwebs here...) minded people can use, understand and be kept secured.
d_theorist 10y ago
>Your browser can easily distinguish these two cases if the new key in the header of the webpage is actually signed with the previous key for the same website (whose public counterpart is stored by the browser). I don't see how this can work. If we need to update keys because of compromise, the keys cannot be relied on to sign the new keys, because they have been compromised. Nor can such a case be pre-announced.
libeclipse 10y ago
What a terrible idea. Granted CAs have their problems, but this is actually worse. Not to mention that this scheme still uses a CA of sorts. Lose-lose.
blueplane 10y ago
Maybe I'm missing something import here, but isn't that just what we had with self-signed certificates and adding security exceptions in the browser?
peterwwillis 10y ago
The author doesn't understand PKI. Certificates provide a host of features that have grown out of the needs of organizations serving users. Public key only really works for SSH because its use case is so incredibly limited. Certificate rotation/expiration/invalidation, multiple certificate per domain, multiple subdomain certificates, multiple feature certificates, a dizzying array of certificate extensions, not to mention the organizational control of their issuance across multiple orgs for the same domain, as well as user certificates, are all necessary and all are abandoned by public key. There's a lot more I don't even remember off the top of my head.
StavrosK 10y ago
I don't see how this proposal is any different (and even any better) from a small red exclamation mark icon next to the padlock that tells the user "you have never visited this website before". All your usual websites wouldn't have this icon, but paypa1.com would, and it would be easy for the user to think "wait, what do you mean I've never visited Paypal before?".
skywhopper 10y ago
This proposal makes no sense. It wouldn't improve security, it just proposes an annoying UI that in itself is a security risk, and the stripping away of several useful features of the current trust system. Critically, unbinding public/private keys from DNS names removes a layer of trust. I trust my browser-maker to grant only legitimate CAs approval to sign certificates that will be accepted by default by my browser, and my DNS provider to send me the correct IP for a given name, and I trust myself that I know the DNS name of the site I want to visit. Those three things work in concert with each other to give me a relatively high level of assurance that I'm talking to the site I mean to be. What's more, thanks to certificates, I can verify this all myself! Export the site certificate, and check its signing chain to go back to the CA, which I can also decide for myself if I want to trust or not, if I don't trust the browser-maker's judgment. Add to that certificate revocation, and I fail to see how the proposed plan makes any sense at all. The author never makes a case that name-based certificates are actually a problem. Browser makers are free to add extra layers of security to the current system that could do what the author proposes. But from little details of what he says I suspect what's really going on is that he just doesn't want to pay for certificates or deal with setting up Lets Encrypt.
foo101 10y ago
This post makes no sense to me. How is the proposed solution where MITM attack could be going on the very first time I visit a website I want to trust a better solution than the current state of PKI? The proposed solution demands that we trust the website on the first visit if the website behaves well. So now it is very easy for Mallory to perform MITM and behave well so that I trust Mallory's public key. Now Mallory can see all my traffic in subsequent visits. How can even one imagine that this is an acceptable solution?
dspillett 10y ago
> TOFU (Trust On First Use) principle ... used by ssh No. That might be how you use SSH, but you are not really using SSH correctly IMO so you are not qualified to tell me HTTPS should run like SSH... For a properly secure connection you should be verifying the fingerprint against a reference you received through a different trustworthy communications channel. If I'm connecting to my own servers I know the value is correct as I setup the server and have record of it. If it is a newly setup machine/VM as a hosting location I might have to go on trust that the first one I see is OK but if I'm connecting to an existing service I expect to be told the fingerprint so I can check it. FYI: in my day job I handle file transfers potentially containing our clients' client data so we have to do this sort of thing properly. Ignoring the "you are doing SSH wrong" thing for a moment, there is another major flaw in TOFU: users will just click OK without thinking when presented with an "are you sure" question. The people most vulnerable to the current problems with TLS are not going to have their risk profile changed at all (or if it changes it'll be for the worse) by this proposal.
- aaronmdjones 10y ago
  Just so you know, in case you don't, you can use certificates for SSH these days. Not X.509, but certificates nonetheless in that they bind a set of names or IP addresses to a public key and signed by a CA you trust, which, for your machines, will be a CA you control. Now I can deploy as many new machines as I like and I only have to sign their host keys for all of my SSH clients across my machines to trust that new machine before I first use it. If this is new information; I have left example instructions at https://paste.debian.net/plainh/6b332023 https://paste.debian.net/plainh/6b332023
  - dspillett 10y ago
    I'm aware of certificate support for SSH, though getting out clients to use something other than what they "have always done" is somewhat painful. It isn't just browser choices and desktop OSs in which they are firmly stuck a decade and a half behind... Certificate for SSH isn't something that the OP is going to like though, as he is trying to use SSH as part of a rational for doing away with certificates for HTTPS...

So, essentially the same way SSH works? The main problem I'd see is training users to get that initial trust phase correct. Too many wouldn't try to parse the info given and just click Trust regardless (or run away from every site with the warning).

icebraining 10y ago
The same way, except SSH is generally used for a small number of hosts that the user itself (or their organisation) controls, so there's some chance for out-of-band verification.
dspillett 10y ago
> So, essentially the same way SSH works? Not if you are doing SSH right... That "fingerprint validation" message you get the first time you connection to a SSH host: you should be verifying that against a copy received through another (preferably secure of course) channel, not just blindly trusting the first fingerprint you are shown.

NeutronBoy 10y ago

Nice writeup - good to see a solution proposed, rather than the same complaints about 'how TLS is broken'! That said, the key flaw that's raised at the start of the article (how do you know that amazon.de is Amazon) is not really solved with this solution. You still need a trusted third party to bootstrap that first visit.

mborch 10y ago
For most people that's currently Google due to search-based location bar.

icebraining 10y ago

1) So I boot my new phone, connect to some coffeeshop's wi-fi and navigate to some HTTPS site. The coffeeshop's captive portal intercepts my request to show me a TOS page, sending me their public key instead. Now my browser has that key remembered for that domain, and will error when I visit the real site. 2) Key rollovers are accepted silently if signed with the previous key. So an attacker who steals the key can sign their valid ones forever, right? If the server can invalidate previous keys to reduce that risk, what happens when the attacker uses that feature themselves against the actual site owners? 3) How is TOFU better than previous proposals like Perspectives and Convergence?

chillaxtian 10y ago
> 1) So I boot my new phone, connect to some coffeeshop's wi-fi and navigate to some HTTPS site. The coffeeshop's captive portal intercepts my request to show me a TOS page, sending me their public key instead. Now my browser has that key remembered for that domain, and will error when I visit the real site. yeah.. this brings us back to basically the same setup as before. your device needs to reach out to some 'trusted party' to ask it whether it should warn you about the key. how does your device connect securely to this trusted party, so someone can't mitm the trust question? ship the trusted parties key on the device. .. sound familiar?
- Qantourisc 10y ago
  Almost, but now you only have to trust one third party, not 189 (/etc/ssl/certs).
  - rocqua 10y ago
    There needn't be a lot of difference, if that single trusted party still signs a lot of other CA certificates. You don't just need to trust the root certificates intsalled, you need to trust all signed CA certificates those root certificates installed (except for public key pinning, which will ignore installed root certificates).
- derefr 10y ago

jstewartmobile 10y ago

It would be progress for the savvy and regression for everyone else, but I still like his thinking here even if it's ultimately a mistake.

icebraining 10y ago
If the savvy want this they can already have it, it's just a matter of removing the certs from the browser's CA store.
- jstewartmobile 10y ago
  He added a few flourishes, like network insights, pre-installed certs, and a signature in the header for key rotation. Might be fun to usability test that scenario in a VM or something just to see how it works in practice.

mholt 10y ago

Having spent a few years dabbling in TLS stuff recently... I have some comments. This article is really about PKI more than TLS, and what it means to be a user's agent ("user agent"). Forgive my critical tone in advance, it's just that proposals like this need to go through the wringer... > you are supposed to be certain that you are communicating with the website you intended to visit. the green padlock in front of the URL in your browser tells you TLS is securing the connection. But this reasoning is wrong. No, it's not. It's correct to reason that the green lock (as implemented by most modern browsers) indicates a secure connection to the site in the URL bar. Now, whether that site is behaving virtuously... is a different matter, and not one that TLS is designed to solve. It also doesn't mean TLS is broken. (TLS is quite good, especially the emerging 1.3 standard. Qualms with TLS usually end up being about PKI, which is the best thing we've got widely deployed right now, whether you like it or not.) "Intended to visit" -- when we look at the browser as the role of the user agent, or in other words, a program that is supposed to act helpfully on behalf of the user -- the browser infers intent from what the user tells it to do. If you have a private chauffeur and you tell him to take you to such-and-such place, he will go there, even if you intended to go to such-another place. Oops? Maybe agents who know you really well could double-check with you if they think you meant something else, but do you really want your browser to know that much about you? > The real solution: get rid of certicificates This is ridiculous. Certificates make possible the cryptographic exchanges that guarantee confidentiality, host (and client) authenticity, and data integrity. Don't throw away the single most valuable component of modern Web security. > Being able to tell that we are visiting the same website as before allows us to establish a trust relationship with that website over time. With every positive interaction, our trust increases (and with every bad experience, our trust drops). We don’t need the website’s name for that. This isn't about TLS, this is now about PKI and trust model issues. Yes, there are various trust models and each have advantages and disadvantages. We went with PKI for the wider Internet because it fits the mold best when connecting machines to other machines at scale. In contrast, WoT and other models (including TOFU) work better in small groups of people or machines in semi-controlled environments (e.g. TOFU is manageable with your small-medium-sized fleet of servers).

iancarroll 10y ago
Agreed. Straight TOFU without CAs is a bad idea usability wise; we're still struggling to get the UI down for padlocks... But when you combine TOFU and CAs, well, you get something like HPKP, which is a good middle ground, I think.

vbernat 10y ago

Putting keys from popular websites would increase centralization: content will be moved to Facebook and the likes to avoid the warning. This TOFU thing could be useful with self-signed certificates (like those shipped in servers' BMC).

icebraining 10y ago
This TOFU thing could be useful with self-signed certificates (like those shipped in servers' BMC). But that's how it already works, at least traditionally (how don't know about Chrome): you connect to it, and the browser asks you if you want to make a permanent exception for that cert. Next time, it'll just connect.
- vbernat 10y ago
  In Chrome, there is no such thing as a permanent exception. In Firefox, the permanent exception includes unexpected certificate change.
  - leni536 10y ago
    > In Firefox, the permanent exception includes unexpected certificate change. I didn't know this. This is horrible and does not make any sense.

lend000 10y ago

No matter what, you have to trust someone, and any method that requires first-time click through every time on every new website is bound to exhaust users, resulting in them clicking through blindly. At least a certificate violation is a rare enough event, although as mentioned, it can potentially be corrupted by the CA. Regardless, you trust the browser implementation. A better solution might have browsers try to intelligently identify suspicious looking URL's (including URL's that start with a popular, external URL, like paypal.com.notpaypal.cc). As for the actual certificates themselves, perhaps this is a good application for a Blockchain technology, with certs being created by website owners and submitted to a Blockchain by a machine assigned to the DNS name that wants to create its cert. But in this case, we still require DNS which is built on trust... so perhaps DNS could also be put on a blockchain. How? I don't know. But until we figure that out, we have to rely on various organizations to provide trust.

dchest 10y ago
resulting in them clicking through blindly In the proposed scheme, they are ALWAYS clicking though blindly. There's no way for a user to know when he gets the original public key or someone else's. How is a user supposed to verify it, call the owners of the website and ask them to dictate their public key? This warning screen is thus just a security theater. The whole proposed "solution" is not a solution at all and doesn't work — the author could have saved a lot of time typing this blog post if they just listed threats that certificates are trying to solve on a piece of paper and put a check mark next to each if their proposed "solution" solves it.

lexman0 10y ago

I completely disagree with this. Public key pinning has some well known problems that make it very dangerous to implement at scale [1]. There are some very large problems that this introduces and does not solve: - How do kiosk machines now work? How can I trust any website when every use is first use? - What about https domains for images and scripts? Is the user supposed to trust each domain separately? - Assuming trusting a domain trusts all its other domains mentioned in its content-security-policy, how is this trust revoked for misuse? - Is the author suggesting that we retain all users of browsers everywhere? I believe that to be a herculean task. Certificates have their problems, but this is not a solution. I will not propose one here, because it is an extremely complicated problem that needs many separate parties working together to solve. [1] https://blog.qualys.com/ssllabs/2016/09/06/is-http-public-key-pinning-dead https://blog.qualys.com/ssllabs/2016/09/06/is-http-public-ke...

__david__ 10y ago
> How do kiosk machines now work? How can I trust any website when every use is first use? Should you ever really trust kiosk machines? They could easily be setup with MITM eavesdropping software. > What about https domains for images and scripts? Is the user supposed to trust each domain separately? Presumably there could be some sort of <meta> header that listed the public key fingerprint/IDs of any subdomains that the page was going to pull in. This would make the UX better. > Assuming trusting a domain trusts all its other domains mentioned in its content-security-policy, how is this trust revoked for misuse? AFAIK, revocation isn't very good even with the current CA infrastructure[1][2]. [1] https://news.netcraft.com/archives/2014/04/24/certificate-revocation-why-browsers-remain-affected-by-heartbleed.html https://news.netcraft.com/archives/2014/04/24/certificate-re... [2] https://www.maikel.pro/blog/current-state-certificate-revocation-crls-ocsp/ https://www.maikel.pro/blog/current-state-certificate-revoca...
- lexman0 10y ago
  > Should you ever really trust kiosk machines? They could easily be setup with MITM eavesdropping software. I should have the choice. This doesn't even give me that. > Presumably there could be some sort of <meta> header that listed the public key fingerprint/IDs of any subdomains that the page was going to pull in. This would make the UX better. This would make the UX barely passable. If any of these domains change the content at all so the hash changes, how does it get updated? > AFAIK, revocation isn't very good even with the current CA infrastructure[1][2]. I completely agree with you, so lets not make it any worse.

chaz6 10y ago

RFC 6844 defines a DNS record (CAA) which supposedly allows you to restrict which CA's are allowed to issue a certificate for your domain. Of course, this is on the honor basis. https://tools.ietf.org/html/rfc6844 https://tools.ietf.org/html/rfc6844

rocqua 10y ago
That can be secured with DNS-Sec, leading to DANE. It is often suggested as either an addition or replacement for the CA system. However, this is basically the CA system in disguise. Instead of trusting CAs, we need to trust domain servers. Thing is, domain servers tend to be controlled by governments even more so than CAs. There are some other issues with the technical implementation of DNS-sec, though I do not recall them at this moment.
- chaz6 10y ago
  I think ultimately you end up having to have a web of trust, but this assumes that the devices of the people in your web have not been compromised (backdoored apps and/or crypto libs).
  - rocqua 10y ago
    I think a system like CAs or DNS-sec, with hierarchical trust is a good base. However, we'd need to add certificate transparency and 'triangulation'. Certificate transparency is a centralized way to detect wrongly-issued certificates. Triangulation is a peer-to-peer way, where a client asks a few other clients what certificate they have. I like a DNS-based approach, because it ensures only one authority can authorize a key, though it has the issue of often being a state-controlled authority.
    - chaz6 10y ago
      I tend to like the DNS approach as it is supposedly non-commercial and non-state operated, but again you have to place your trust in a group of people you do not know (I have never met one of the root signers before), so you have no way to know if they or their equipment have been compromised by a state actor.

KentLatricia 10y ago

This article seems to miss the point that a website rarely serves content from a single domain. If it pulls content from 30 different domains, all TLS protected, would the user get 30 popups asking it to allow them each? The current TLS/PKI allows for much better UX, users would reject the proposed solution.

philliphaydon 10y ago
Someone suggested some sort of metadata that could be passed down to the browser to say this list of domains or such are valid. But if the website is hacked to have injected metadata put in then I kind of think that's ever worse than the current problem. It gives trust to a domain implicitly.

Johnny_Brahms 10y ago

Moxie had a talk called "SSL and the Future of Authenticity" at blackhat about an old project of his called Convergence. The talk is on youtube. https://en.wikipedia.org/wiki/Convergence_(SSL) https://en.wikipedia.org/wiki/Convergence_(SSL)

deleted 10y ago
[deleted]
y7 10y ago
It's a shame Convergence was discontinued. I think it was a good solution to the problem.

Aissen 10y ago

There are browser extensions to implement TOFU. Just use that if that's your thing, don't make the rest of us insecure please.

lsiebert 10y ago

key rotation and signing with the previous key doesn't work for credentials that are compromised. It also potentially fails for devices that miss a whole key rotation, which could happen for devices that aren't regularly connected to the internet but still need access for things like firmware upgrades.

lsiebert 10y ago

d_theorist 10y ago

The Netherlands is an 'evil government'?

majewsky 10y ago
Depends on perspective (although I guess that the US would've been a better example). There are many people who consider the Chinese government as much not evil as you do the government of Netherlands.

jlgaddis 10y ago

> ... a system where ... information about the domain being visited is displayed from various sources (e.g. Google, or known phishing domain databases like PhishTank) that have a global network picture and hence are in a unique position to tell very early on whether a certain domain is untrustworthy. So, a trusted third-party, then? To, you know, certify the site? Like... a Certification Authority, perhaps? > If this is the first time you are visiting this website, a warning message will appear. Your browser will provide some useful information about this site (see below) and ask you whether you want to continue and really visit this site. How's that going to work when visiting any of the majority of sites today that pull in resources from perhaps 20 or more different domains? Google Analytics, some other analytics, ads, all the trackers, ... On a whim, I just pulled up CNN's web site [0]. uBlock Origin reports a total of 21 domains. How is the average user supposed to know if zor.fyre.co is legitimate -- or a tracker or a phishing site or "evil Russian hackers" and shouldn't be trusted? There's a lot that's wrong with the current state of PKI on the web (too many CAs, questionable CAs, etc.) but that doesn't mean we should just throw it all out tomorrow. We're stuck with it -- at least until something better is devised and rolled out (which would take years!) -- so the best we can do is hope for continued incremental improvements, such as TLS 1.3. [0]: http://www.cnn.com/ http://www.cnn.com/

rictic 10y ago
I don't want a web where every time a user visits a new domain they see a scary interstitial warning that asks them to make a trust decision. We have too many centralizing forces already.
- Crosseye_Jack 10y ago
  > I don't want a web where every time a user visits a new domain they see a scary interstitial warning that asks them to make a trust decision. I don't want it either as it easily trains users to click though it. User goes to new website: "Oh yeah I have to click allow <CLICK>"... User returns to site but its now being MITM'ed: "Oh I thought I had clicked allow. <CLICK>"... Even if the warning is something like "the public key for this site has changed, do you wish to continue?" The gen public will click continue. The problem is not designing a system us on hacker news can use, understand and keep us secure but its building a system that "non-technical" (Throw in generalisation about parents/grandparents not understanding the interwebs here...) minded people can use, understand and be kept secured.

d_theorist 10y ago

>Your browser can easily distinguish these two cases if the new key in the header of the webpage is actually signed with the previous key for the same website (whose public counterpart is stored by the browser). I don't see how this can work. If we need to update keys because of compromise, the keys cannot be relied on to sign the new keys, because they have been compromised. Nor can such a case be pre-announced.

libeclipse 10y ago

What a terrible idea. Granted CAs have their problems, but this is actually worse. Not to mention that this scheme still uses a CA of sorts. Lose-lose.

blueplane 10y ago

Maybe I'm missing something import here, but isn't that just what we had with self-signed certificates and adding security exceptions in the browser?

peterwwillis 10y ago

The author doesn't understand PKI. Certificates provide a host of features that have grown out of the needs of organizations serving users. Public key only really works for SSH because its use case is so incredibly limited. Certificate rotation/expiration/invalidation, multiple certificate per domain, multiple subdomain certificates, multiple feature certificates, a dizzying array of certificate extensions, not to mention the organizational control of their issuance across multiple orgs for the same domain, as well as user certificates, are all necessary and all are abandoned by public key. There's a lot more I don't even remember off the top of my head.

StavrosK 10y ago

I don't see how this proposal is any different (and even any better) from a small red exclamation mark icon next to the padlock that tells the user "you have never visited this website before". All your usual websites wouldn't have this icon, but paypa1.com would, and it would be easy for the user to think "wait, what do you mean I've never visited Paypal before?".

skywhopper 10y ago

This proposal makes no sense. It wouldn't improve security, it just proposes an annoying UI that in itself is a security risk, and the stripping away of several useful features of the current trust system. Critically, unbinding public/private keys from DNS names removes a layer of trust. I trust my browser-maker to grant only legitimate CAs approval to sign certificates that will be accepted by default by my browser, and my DNS provider to send me the correct IP for a given name, and I trust myself that I know the DNS name of the site I want to visit. Those three things work in concert with each other to give me a relatively high level of assurance that I'm talking to the site I mean to be. What's more, thanks to certificates, I can verify this all myself! Export the site certificate, and check its signing chain to go back to the CA, which I can also decide for myself if I want to trust or not, if I don't trust the browser-maker's judgment. Add to that certificate revocation, and I fail to see how the proposed plan makes any sense at all. The author never makes a case that name-based certificates are actually a problem. Browser makers are free to add extra layers of security to the current system that could do what the author proposes. But from little details of what he says I suspect what's really going on is that he just doesn't want to pay for certificates or deal with setting up Lets Encrypt.

foo101 10y ago

This post makes no sense to me. How is the proposed solution where MITM attack could be going on the very first time I visit a website I want to trust a better solution than the current state of PKI? The proposed solution demands that we trust the website on the first visit if the website behaves well. So now it is very easy for Mallory to perform MITM and behave well so that I trust Mallory's public key. Now Mallory can see all my traffic in subsequent visits. How can even one imagine that this is an acceptable solution?

dspillett 10y ago

> TOFU (Trust On First Use) principle ... used by ssh No. That might be how you use SSH, but you are not really using SSH correctly IMO so you are not qualified to tell me HTTPS should run like SSH... For a properly secure connection you should be verifying the fingerprint against a reference you received through a different trustworthy communications channel. If I'm connecting to my own servers I know the value is correct as I setup the server and have record of it. If it is a newly setup machine/VM as a hosting location I might have to go on trust that the first one I see is OK but if I'm connecting to an existing service I expect to be told the fingerprint so I can check it. FYI: in my day job I handle file transfers potentially containing our clients' client data so we have to do this sort of thing properly. Ignoring the "you are doing SSH wrong" thing for a moment, there is another major flaw in TOFU: users will just click OK without thinking when presented with an "are you sure" question. The people most vulnerable to the current problems with TLS are not going to have their risk profile changed at all (or if it changes it'll be for the worse) by this proposal.

aaronmdjones 10y ago
Just so you know, in case you don't, you can use certificates for SSH these days. Not X.509, but certificates nonetheless in that they bind a set of names or IP addresses to a public key and signed by a CA you trust, which, for your machines, will be a CA you control. Now I can deploy as many new machines as I like and I only have to sign their host keys for all of my SSH clients across my machines to trust that new machine before I first use it. If this is new information; I have left example instructions at https://paste.debian.net/plainh/6b332023 https://paste.debian.net/plainh/6b332023
- dspillett 10y ago
  I'm aware of certificate support for SSH, though getting out clients to use something other than what they "have always done" is somewhat painful. It isn't just browser choices and desktop OSs in which they are firmly stuck a decade and a half behind... Certificate for SSH isn't something that the OP is going to like though, as he is trying to use SSH as part of a rational for doing away with certificates for HTTPS...