Live data from Hacker News

Iran forged the wrong SSL certificate

daemonology.net

51–60 of 115 posts

Re: Iran forged the wrong SSL certificate

#52

Earlier quoted context omitted.

The average person on the coffee shop wifi isn't an SSL CA, and that's what "always on https" is defending against. SSL doesn't protect you from someone breaking into your house with a gun and forcing you to reveal your email archive. But that doesn't mean it's not useful.

I'm aware of this; however, I'm just pointing out the ironic timing of these exploits. You teach people to fear one thing, and in this case, they leap head first into something even further beyond their comprehension. They need to start teaching Internet 101 classes in middle school.

> You teach people to fear one thing, and in this case, they leap head first into something even further beyond their comprehension.

Which, in this case, was the right thing to do.

Re: Iran forged the wrong SSL certificate

#53
post #17

A solution: http://www.convergence.io

Hmm, sounds like an exact copy of Perspectives: http://perspectives-project.org/

It is indeed based on Perspectives. But the implementation provided with Perspectives does not have privacy. If you contact a notary with Perspectives then that notary has your browsing history. See 36:50 on http://www.youtube.com/watch?v=Z7Wl2FW2TcA

Re: Iran forged the wrong SSL certificate

#55
post #49

Earlier quoted context omitted.

> can you do something alternative which allows you to have a like button, but without including third party script? How about create a JavaScript library that sandboxes execution of third-party scripts by loading them in iframes based off of a different domain? This would allow site owners to embed Google Analytics or FB Like buttons without worrying about the third-party scripts getting compromised or becoming mali…

Most social plugins already have an iframe option. E.g. search for iframe in http://developers.facebook.com/docs/opengraph/ Edit: I think I may have misunderstood you. Did you mean embed an iframe and using postMessage to control it?

There's a difference between the iframe version of Facebook's like button and the XFBML version. The XFBML version, for various reasons, is preferable to the iframe version (e.g. say you want to subscribe to the edge.create event to determine if someone clicked on the like button).

Now, if you want to add the XFBML version of the like button, you'd have to embed Facebook's JavaScript SDK script (https://connect.facebook.net/en_US/all.js) to your site. If connect.facebook.net ever gets compromised via a fake SSL certificate, your site will also be compromised.

Instead of letting third-party scripts run on your main site, it may be safer to let them run within an iframe based off of a different domain so that a compromised third-party script doesn't compromise your main site.

Re: Iran forged the wrong SSL certificate

#56
post #53

Earlier quoted context omitted.

Hmm, sounds like an exact copy of Perspectives: http://perspectives-project.org/

It is indeed based on Perspectives. But the implementation provided with Perspectives does not have privacy. If you contact a notary with Perspectives then that notary has your browsing history. See 36:50 on http://www.youtube.com/watch?v=Z7Wl2FW2TcA

Very interesting, thank you. It looks like it solves very significant problems in a very good way (I'm amazed the Perspectives guy missed them, especially sending the certificate to Perspectives like Convergence does).

I really, really hope this catches on and gets built into browsers...

Re: Iran forged the wrong SSL certificate

#57

How come it's just one CA that is needed to ensure the trust of a domain, especially one as important as *.google.com? It seems like it's only a matter of time before something like this happens again.

The idea is that all CA's are effectively fully trustworthy. The public keys for the CA's certs are loaded into browsers. When a specific SSL cert is created the private key is generated by the buyer (and never revealed) then the public key for that is sent to the CA and signed. In this way a link of trust is created between the CA and whoever bought the SSL cert. Now, when a browser is used to go to a website using…

The said chrome will only accept one particular CA when verifying the signature for google.com (which is one of the reason the fraudulent cert was detected).

Re: Iran forged the wrong SSL certificate

#59
post #57

Earlier quoted context omitted.

The idea is that all CA's are effectively fully trustworthy. The public keys for the CA's certs are loaded into browsers. When a specific SSL cert is created the private key is generated by the buyer (and never revealed) then the public key for that is sent to the CA and signed. In this way a link of trust is created between the CA and whoever bought the SSL cert. Now, when a browser is used to go to a website using…

The said chrome will only accept one particular CA when verifying the signature for google.com (which is one of the reason the fraudulent cert was detected).

This should be a feature they offer to all of the Alexa top 100 websites.

Re: Iran forged the wrong SSL certificate

#60
post #28
post #17

A solution: http://www.convergence.io

And how do you choose who to trust? Until this incident DigiNotar seemed trustworthy.

here's a blog post Moxie wrote that explains "Trust Agility": http://blog.thoughtcrime.org/ssl-and-the-future-of-authentic...
Post reply on HN