It's Time to Fix HTTPS

https://docs.google.com/present/view?id=df9sn445_206ff3kn9gs&pli=1

by fogus • 15 years ago

376 120 15 years ago

docs.google.com

huhtenberg5• 15 years ago

YES. Please somebody make this.

Paint me paranoid, but CA-assisted man in the middle attacks is a real source of concern for me. I would absolutely love to have the SSH-style trust model for my HTTPS connections and I will pay good money for an implementation. A simple browser plugin that implements TOFU/POP on top of PKI would be an excellent start.

tptacek22• 15 years ago

How is key continuity any better than PKI against man-in-the-middle attacks? The tradeoff is simple: every first introduction between a browser and a website is insecure, so that subsequent connections might be less insecure.

This doesn't look like a win to me. Browsers are introduced to websites all the time.

To me, this solution looks like "let's accept an ambient loss of ~5-10% of all connections to MITM attacks, because it's politically too hard to configure the PKI-based SSL protocol properly".

huhtenberg5• 15 years ago

> Browsers are introduced to websites all the time.

I care most about a handful of sites, most of which are controlled either by me or by people I trust. My co-located mail server would be one of these sites.

Skalman• 15 years ago

Read this sentence again: A simple browser plugin that implements TOFU/POP on top of PKI would be an excellent start.

That would - at least to start with - be additional security.

mentat• 15 years ago

"every first introduction between a browser and a website is insecure, so that subsequent connections might be less insecure."

I think the claim is that this is already the case. There are certificate signing certificates in the hands of people who should not have them and there's no accounting of who has them (beyond the government mentioned) or what they're doing with them. I don't think this presentation is suggesting deleting all your installed CAs, just monitoring whether things are changing under you and coordinating those observations with others you trust. The coordination certainly goes beyond on the SSH model.

nikcub• 15 years ago

> SSH-style trust model for my HTTPS connections and I will pay good money for an implementation

You can do that now. Note the cert ID first time you login. If it is different the next time you login, then it is a different cert.

This would be an easy browser extension.

jmillikin6• 15 years ago

You can have it today! No money or plugins needed. And it only takes a minute to get started.

Just delete your CA list.

Go into your browser's preferences. Find the "security" section. It should have a button to open up the list of trusted certificate authorities.

Delete them all.

Now, every time you connect to a secure page, one of two things will happen:

1. If you've never visited that page before, your browser will prompt you for instructions. Use whatever means you like (second browser, remote server, call them, etc) to verify the server's SSL fingerprint. If it checks out, mark it as valid (aka "add an exception").

2. If you have visited that site before, its exception will already be present in your browser, and it will work like normal.

After a few days of this, you'll see why the SSH model hasn't seen widespread adoption for HTTPS.

huhtenberg5• 15 years ago

Ha-ha-ha. Not too practical, is it?

There are my own servers and there is the rest of the Internet. I want to use self-signed certs on my servers and I want these to be sticky. If any of these servers would suddenly start presenting different certificates (most notably, signed by a CA that sits on browser's trusted list), I want to know about this lovely fact.

For the rest of the Internet I can live with existing PKI.

Udo3• 15 years ago

What you describe is exactly the behavior the author calls "Firefox' war on self-signed certificates". The actual proposal calls for a browser that does NOT prompt the user all the time. It would just prompt when something extraordinary happens (such as the server's already known certificate changing).

> After a few days of this, you'll see why the SSH model hasn't seen widespread adoption for HTTPS

That's not really true. It has simply never been done for browsers, because many people think it's an abomination and, to paraphrase well-known HNers from previous discussions, supposedly useless and little more than obfuscation instead of encryption.

It's not the first time TOFU/POP has been suggested on HN, too. I find it curious this proposal got so many upvotes here today. I don't remember that many people coming to mine and other people's defenses when we suggested the exact same thing a few months back and crypto gurus were rending their hair like we had committed the most stupidly blasphemous act conceivable to modern computer science.

kahawe2• 15 years ago

Ever since they changed Firefox's behavior when an unknown certificate is encountered this would be especially crippling.

I can understand why this might be a good feature to have for end-users and internet novices but why isn't there an option to revert it back to the old "yes/no" box instead of having to click 5 times when I know exactly why there is a self-signed certificate in use...

Also, considering this:

> Global PKI, as currently implemented in browsers, does not work.

makes this feature even more dubious and even worse, together with the green SSL indicator it gives a false sense of security.

mukyu• 15 years ago

http://www.networknotary.org/firefox.html

https://addons.mozilla.org/en-us/firefox/addon/certificate-p...

Joakal3• 15 years 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.

jmillikin6• 15 years 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

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• 15 years ago

The extension https everywhere auto-encrypts wikipedia

https://www.eff.org/https-everywhere

Joakal3• 15 years 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?

kevinchen2• 15 years 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.

julian375• 15 years 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 :-)

halo3• 15 years 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.

tbrownaw2• 15 years 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.

pyre• 15 years 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!

tptacek22• 15 years 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.

Joakal3• 15 years 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.

noahl• 15 years ago

I like the ideas presented in here.

Summary of what I think the main points are:

- certificate authorities are not trustworthy currently. It is deceptive and potentially dangerous to pretend that they are.

- the solution is actually a shift in what we think security is: rather than saying "this site is trustworthy" or "this site is not", we consider multiple factors to decide whether it is likely to be trustworthy or not.

My thoughts: I think the second point is an excellent idea, and I would take it farther by presenting that information to the user.

It would be great if there were a little meter in my URL bar that was more full (or changed color, or whatever) when a site used more secure practices. It would be even better if I could click on that meter and get a list of things the site did, with a note by each one saying "a trustworthy site would do this" or "a trustworthy site would probably not do that".

This would have the benefit of making the security model transparent to the user, which would let them make better decisions.

It would also allow for experimentation with new security ideas, if we allow many possible factors and not expect each site to use all of them. You could easily add a factor for sneakernet key-signing, for instance - if you happen to have a cert directly from the company (i.e. your bank gave you a USB key), your browser could take that into account.

Edit: it would also allow for a gradual transition from the old model. You could make having a CA-signed key a factor. It just wouldn't be the only factor.

talmai• 15 years ago

At first I thought "The title is bait.... what a waste of time, etc...". Clearly the problem isn't HTTPS, it is the current CA structure. I then went on Chris' site (http://noncombatant.org/) and there he summarizes it well: "The problems are social and economic more than technical. The technical problems are in usability, not in cryptography. In general, security people should start learning about usability."

I still argue that the is no 'usability' problem, but rather 'ignorance'. The fact that https has been hailed as 'secure' to the user (who has no formal understanding of what 'secure' is) is what has led up to the problem he is venting about...

alanh• 15 years ago

I’m not sure that usable security is possible. In general, it’s the pattern that security requires less than ideal user experiences. For example, being emailed your password when you forget it would be “nicer” than getting a password-reset link, but requires breach of server-side best practice; not having to use a password at all would of course be the very easiest and least secure “solution” for authentication; the most secure measures require two-factor authentication and are necessarily the most annoying.

The observation of this pattern is perhaps obvious, but important.

eiji• 15 years ago

It's time to fix ppt-misuse.

Please don't present a complex topic with 87 slides.

tptacek22• 15 years ago

I think it's important to know that, whether you agree with this deck that key continuity ("tofu/pop") is a better approach than PKI or not, what we're talking about here is a misconfiguration of SSL caused by a political quandary, not a fundamental problem with SSL/HTTPS.

The fact is, if your browser trust roots contain only trustworthy CA's, and you look to make sure you're using a secure site when you expect to, SSL isn't broken. Those sound like two big "ifs", and they may be, but consider: they are both user interface issues:

* There is no collaborative interface for community-rating CA trustworthiness, or even a reasonable interface for pruning CA's out of your browser --- let alone "do I trust certificates delegated from this CA, or just the CA itself". We are still using an interface for this functionality designed in the mid-'90s.

* The "first introduction" problem that key continuity suffers from is, in the SSL case, caused by the fact that the SSL cues in the browser are subtle. But why should that be the case? Is there really no interface anyone can come up with that appropriately signals "this page should be and is secured by SSL"? Because if you have that (or STS), sslstrip doesn't work.

Key continuity's problems, on the other hand, aren't user interface issues. In key continuity schemes, when your browser is first introduced to a new website, you simply are insecure. If at that moment you are MITM'd by an attacker, you might never again be secure. This isn't a UI issue: key continuity protocols don't have the information available to them on first connection to make that decision.

Think to yourself, if you ran the great firewall of China, which system you'd rather have: the flawed one we have now, or the one that explicitly allows your connection on the first and subsequent connections to a new service to be hijacked?

I am our resident SSL/TLS apologist. But let me be clear that this deck is good, and raises a lot of valid concerns. I think SSL/TLS is a good system, but I share the (implied) disgust at the way our PKI has been managed. Some kind of reform is needed. I just don't think it needs to come with additional engineering sacrifices.

gorset2• 15 years ago

The fundamental problem is with X.509... It uses a flat namespace so all CAs can issue a valid certificate for any domain on the internet. Much of the problem could have been avoided if it was using a proper hierarchical structure, e.g. mirroring DNS, so only a .com CA could create a valid google.com certificate.

caf6• 15 years ago

Completely agreed. Note under such a system we wouldn't have even had to create separate CAs - it would have been natural for DNS registrars to take on this role, signing a certificate for your domain at the same time that they delegated your name server records. Certificate expiry dates could have been directly linked to domain registration expiry dates.

Under such a system, you'd know that you were only at the mercy of the Chinese government when browsing .cn sites - which is neither unsurprising nor too much of a worry.

modeless3• 15 years ago

In key continuity schemes, when your browser is first introduced to a new website, you simply are insecure. If at that moment you are MITM'd by an attacker, you might never again be secure. This isn't a UI issue: key continuity protocols don't have the information available to them on first connection to make that decision.

What if you add that information to a key continuity system? I feel like this is an obvious idea, but I've never heard of a system using it. It's simple: when you first see a certificate you send it to a trusted third party to check. That third party doesn't need to be or even know about the CA who originally issued the cert; all it has to do is make its own connection to the server and make sure it gets the same cert you did. That protects against any MITM on your end of the connection.

To succeed, a MITM would have to control either the server's connection (which becomes the server operator's problem), or both your connection and the trusted third party's connection (which becomes the trusted third party's problem). I'd rather trust a single third party of my choosing than a huge list of CAs chosen by an opaque and somewhat arbitrary process.

tbrownaw2• 15 years ago

Perspectives (mentioned in the slides) goes a couple better: multiple third parties that poll sites and keep a history of what cert they offer.

kgo2• 15 years ago

There are multiple hops from you to the server. That scheme would only verify that BOTH your and the third party's initial hops haven't been simultaneously MiTM'ed. It's very possible the routes overlap for several hops.

And even if they didn't, I wouldn't consider hackers getting my bank info-- or governments reading my email-- the server operator's problem.

ChuckMcM• 15 years ago

Raise your hand if you've been to a PGP signing party.

Key management is the weakest link of HTTPS/TLS. And the slide deck does a good job of identifying some of the forces that weaken it still further. It assumes (I believe correctly) that the various actors in this play are all working with their own self interest at heart.

So "tofu/pop", to be an improvement (rather than simply training people to click 'ok' on a lot of pop-ups) needs to have some counteracting forces.

But we don't have CA's which get their CA status revoked when they are shown to have given out untrustworthy certificates, nor do we have liability concerns on the browser maker for failing to warn you that something suspicious was going on, and we don't have nation state actors who will transparently step into the game.

I don't have a good answer, but something that is purely algorithmic is going to be challenging to get right. We trust the bank when we walk up to the brick and mortar office because the cost of 'fooling' average people would be too high to build this sort of ruse. However we have no way to currently transfer the trust of the bank to its presence on the web site. An example of that would be taking home a 'certificate' key from the branch manager and then using it at home.

I started looking at this as part of some Java security work in the 90's and got to appreciate just how difficult a problem set it is. And worse, the group that does the infrastructure has to be 100% open so that folks will trust it and 100% free so that it will be widely adopted. That makes for a very very difficult business model.

kragen2• 15 years ago

I used to work with Allan Schiffman, although well after Terisa, so I have my own share of SSL/TLS distaste, but I agree that it's basically workable, and I agree with you that the current PKI is broken. However, I think Chris, Seth, and Peter are right about how badly broken it is, and you're wrong. Specifically:

> Think to yourself, if you ran the great firewall of China, which system you'd rather have: the flawed one we have now, or the one that explicitly allows your connection on the first and subsequent connections to a new service to be hijacked?

The one we have now explicitly allows your connection on the first and subsequent connections to a new service to be hijacked by the Chinese government, assuming they can get your packets to go to them, because CNNIC has a CA cert in your browser. (Have you removed it? I haven't. I didn't know it was there.) Additionally, it allows any connection to any service, old or new, to be hijacked, even if you previously connected to that service without being hijacked, and it doesn't leave any evidence that this has happened. TOFU/POP solves these additional problems, without solving the introduction problem.

It's possible to solve the introduction problem --- which is what CAs do --- in a variety of more or less secure ways. SSH gives you a key fingerprint and prompts you, which pretty much pushes the problem back on the user. But you can do better than that in a bunch of ways.

tptacek22• 15 years ago

... so, remove the CNNIC cert.

What's the issue here? CNNIC isn't trustworthy. You should get a warning every time you visit a CNNIC-signed site.

I don't understand how people can build entire advocacy campaigns on getting other people to switch from IE, but removing untrustworthy certificates? Time to scrap the protocol and move to a crappier one that we can at least get our heads around!

azernik• 15 years ago

I agree that the "first introduction" is an issue, but the use of Perspectives and key signing seems to be a fairly strong attempt to overcome that.

A stronger disagreement: after the presentation puts so much time into linking the structure of PKI and the social incentives that mess it up, to just handwave that away as "a misconfiguration of SSL caused by a political quandary" is kind of missing the point. Any system designed with security in mind must take into account the human factor from the start; human behavior cannot be changed independently of the system's structure.

_b8r0• 15 years ago

> Is there really no interface anyone can come up with that appropriately signals "this page should be and is secured by SSL"?

The problem with first introduction is that while this is great for technical people, it will not pass the Bill Gates' mum test. I'm not saying that TOFU/POP is or isn't the right approach, I'm highlighting that there would be some resistance to change from people who don't understand and don't want to understand.

Introducing (from a tech luddite's perspective) a complex intermediary step to getting online to a bank or ecommerce site is going to be something that people work against. Some people don't actually care that the government may listen in (for various values of people, care and government).

I pretty much agree with 99% of what you're saying. I think this is a big problem and also political. I have no idea what the answer is though.

> Think to yourself, if you ran the great firewall of China, which system you'd rather have: the flawed one we have now, or the one that explicitly allows your connection on the first and subsequent connections to a new service to be hijacked?

This would be fairly straightforward to implement for the Chinese government. Another way to do this is to get your CA accepted (as has happened with CINIC) by default in various web browsers and abuse that.

rwmj• 15 years ago

The fact is, if your browser trust roots contain only trustworthy CA's

That would be the empty set, because neither have I any idea of what criteria I'd use to trust a CA [1], nor do I trust CAs not to give up their private keys to the govt given even the slightest pressure.

[1] Thinking about it a bit more: I'd trust a CA that I'd set up myself. But I wouldn't necessarily trust the hardware it was running on.

swah• 15 years ago

Mind: "No sire, that right now would be procrastination! Lets just use HTTPS as it is..."

alienfluid• 15 years ago

Digital Signatures are only good for specifying identity, not authenticity. Perhaps this fact should be explained in colloquial English for users.

HerraBRE• 15 years ago

It was in the slides, but for those who are too lazy to go through them all: install Certificate Patrol if you are using Firefox.

It adds TOFU/POP style behavior to Firefox and really should be a default feature of all browsers.

jdp23• 15 years ago

"If people don't understand it, we engineered it wrong."

Indeed.

billybob• 15 years ago

Yes. To clarify: if people don't understand how to use it, it's engineered wrong.

teyc• 15 years ago

Even if the CA is cheap and sloppy, an effective attack requires MITM through subverting DNS. This requires the attacker to either have access to the machine or access to the routing equipment. If the attacker owns the machine then it is already game over.

So the remaining threat is if the attacker gains access to the routing equipment, for instance a public WiFi access point or a government.

In the case of a government doing a MITM attack, then the easiest way is to subvert the download sites, so that firefox, MSIE etc includes CAs that the government is in control of. There is no solution for this attack, since both TOFU/POP and CAs are subverted.

In the second case, where public WiFi is under control of criminals, then TOFU/POP has more general applicability. In fact, a change of CA is probably a sign that the connection has been tampered.

aidenn0• 15 years ago

I'm not convinced that tofu is the correct solution, but every criticism of https is true. In addition, it requires a public ip, something that may become scarce soon. I think that tofu combined with sites that poll is possibly a solution. Then you can crosscheck, and revoke authorities without bringing the whole system down. It would also make it harder for governments to mitm, since they would have to subvert many places instead of just one.

zokier• 15 years ago

TOFU would be a lot nicer if certificates were hierarchical, ie. I could say that trust this CA for all *.citibank.com certs. Wildcard certs mitigate the need for that a little, but they are bit more insecure (imho. with wildcard cert attacker needs to gain access to any of your servers to impersonate any other server. With individual certs, attacker needs to either gain access to your CA or is only able to impersonate the compromised server).

Of course transition period would be bit painful if everybody would begin signing their own certs. Tracking individual certs allows much nicer transition, as the certs can continue to be signed by global CAs, but then citibank-like solutions would be problematic.

GrandMasterBirt• 15 years ago

I must agree... Heres an sisue. 99% of the time there are no CAs for a https of a regular site that usually uses http. HOWEVER there is no problem with the certificate.

What does that mean? It means that when looking at the fun little multi step accepting certificates bells and whistles that FF throws I have absolutely no way of knowing if there is a 3rd party. There is nothing helping me out. And I am a "power user". Put those messages to a regular user and you get 3x as dumbfounded. So if 99% of the people don't understand WTF is going on, how can we help prevent any fraud?

__david__3• 15 years ago

Maybe it's time to give D. J. Bernstein's CurveCP (http://curvecp.org/) another look. I quite liked the private "key as endpoint" technique that allowed moving a connection across IP addresses without disconnecting.

gommm• 15 years ago

If like me, you live or travel to China and were horrified at the idea of having CNNIC be an accepted CA in your browser, check this link out: http://www.imminentweb.com/technologies/remove-cnnic-ca

drdaeman• 15 years ago

Let's think rationally. Who can add to certify that your site is, indeed, yours?

- First, hosting provider. They can say "yeah, that stuff's on our network". There's IPsec, but no public keys float around, so it's only for VPNs now.

- Second, DNS registrar. They can say "yeah, that's the domain registered with us". That's already invented and called DNSSEC, although browsers should query for CERT records.

- Third, the notary. That's the current X.509 PKI with CAs. It is NOT broken, it's just insufficient and misunderstood.

- Fourth, yourself. Self-issued certificates can be, in fact, highly trusted, if you met site owner personally and verified the fingerprints. Or they can mean virtually nothing, if you don't know their source.

- Fifth, others. "We cooperate with those guys, they provide us nice stuff, everything works smoothly, and we trust them", "Been there, had everything I wanted, seen nothing weird, trust those guys". WoTs are extremely powerful, as they correspond to natural human trust networks. Implementation, is, of course, hard.

Obvious part of solution would be to allow multiple signatures, so the trust diagram would be a graph, not a tree.

Nelson69• 15 years ago

I'll chime in on this.. Some buddies and I have been debating this since the comodo stuff first started leaking out.

First off, there is a different sort of modern attack that's far worse than most others, and it's attacking the trust model. TLS and PKI hasn't been broken, the way it is used and managed has raised some questions though. The thing that can happen here, a lot of people will just jump ship on it all (and quite honestly, there isn't an alternative right now, the alternative is no security) and that's not good. This is happening a couple different ways, first people don't understand it, second people are raising fears over foreign CAs being included in browsers and OSes.

It seems like the bigger problem to me is that PKI is a dynamic system and the implementations are all static. When a web site is authenticated, the browser could establish a connection to the CA provide, signed by another CA even, and check to see if it has been revoked, if it has been signed, etc.. It could actually verify the third party authentication, live in real-time. To fake a site you'd need to compromise 2 different CA's in that case. And revocation certificates could be sent and honored, in real-time.

It seems to me like it's all rooted in the pay for security model. CAs need to verify each other and the distribution of a new CA needs to be a fairly steep and difficult thing to do (not impossible, but maybe face-to-face contact is required) and any hint of mis-use needs to result in revocation.

xbryanx• 15 years ago

Am I the only one who is frustrated by Hacker News' domain abbreviation with links like this? It makes the link look like it's from Google, and not just a hosted google doc. Could the URL abbreviation change to include subdomains as well?

kennu• 15 years ago

There is also a longer paper (mentioned in the presentation) dealing with this issue from a specific point of view:

http://files.cloudprivacy.net/ssl-mitm.pdf

Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL (Christopher Soghoian and Sid Stamm)

It makes it very clear how every trusted CA in the world currently has the power to circumvent the security of any https-protected website; by themselves or compelled by someone else.

speleding• 15 years ago

I am not a big fan of more government involvement in just about anything, but I can see a role for government here. They are in the best position to establish identity, have little profit incentive, and have ample experience with comparable trust processes like issuing passports and bank notes.

Yes, it will be done less efficiently and with less innovation than the market. That trade off would be worth it.

It's Time to Fix HTTPS

Related Stories