
The Internet's Secret Back Door - jancona
http://www.slate.com/id/2265204
======
augustl
I don't understand how SSL can be secure. Aren't the keys for encrypting and
decrypting transferred in the open before encryption can take place? If so,
isn't a man-in-the-middle able to snoop those keys?

~~~
asmithmd1
I like this analogy for how keys are exchanged and never exposed in transit:

I put my secret in a box and put a lock on it for which only I have the key
and ship the box to you. When you receive the box you put your own lock on the
box for which only you have the key and send the box now with two locks back
to me. When I get the box I take my lock off and send it back to you. Finally
you open the box by taking your lock off. The box is always locked in transit
and no keys were ever out of the owners hands.

~~~
brownleej
I don't think this is the method SSL uses, because what you're describing is
just a variant of symmetric-key encryption. I think SSL uses asymmetric-key
encryption. The better metaphor for that is a lock that anyone can lock, but
only one person can unlock.

~~~
jacobolus
That’s how SSL/TLS does the authorization step, but the typical encryption of
the actual content sent back and forth uses a symmetric-key block cipher (the
two sides negotiate and it’s pretty modular, so I think you can do whatever
kind of encryption you want on the messages, even just sending plain text
after a TLS handshake if you want).

See <http://en.wikipedia.org/wiki/Cipher_suite>

~~~
brownleej
True, but my point was that the actual key exchange (that is, the exchange of
the symmetric keys used for the bulk of the encryption) is done using
asymmetric-key encryption. Since this was in response to the question of how
keys are exchanged, I thought it was the relevant phase to discuss.

~~~
jacobolus
Except, not necessarily, no. Sorry, my grandparent post should have been
clearer that using a public-key method is only one of the ways to do
authentication in SSL/TLS. Either way, some symmetric cipher is used for all
the content.

See: <http://www.ipa.go.jp/security/rfc/RFC2246-AFEN.html>

Search down for Diffie-Hellman.

The Wikipedia article might also be useful:

<http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange>

------
jleader
I don't know enough about certificate revocation lists (CRLs) to be sure, but
isn't it possible for individual browser users to import them?

In that case, couldn't the EFF or similar organizations take matters into
their own hands, and release lists of certificates they think users should be
cautious about?

I suspect libel laws make this more difficult, but perhaps not impossible, if
revocation providers are careful not to overstate their case, but just say
"here's a list of certificates of organizations who have been documented to
meet the following criteria...".

[Edited to add:]

[http://en.wikipedia.org/wiki/Revocation_list#Publishing_Revo...](http://en.wikipedia.org/wiki/Revocation_list#Publishing_Revocation_Lists)
says that "To prevent spoofing or denial-of-service attacks, CRLs usually
carry a digital signature associated with the CA by which they are published.
To validate a specific CRL prior to relying on it, the certificate of its
corresponding CA is needed, which can usually be found in a public directory."
It's not clear whether the browser checks this signature, or whether the user
is expected to. In the latter case, a CRL could be signed by the 3rd party
revocation provider instead.

------
js2
tl;dr - the article is about the susceptibility of SSL protected websites to
man-in-the-middle attacks due to the CA trust model being only as strong as
the least competent/trustworthy CA that a given browser, well, trusts.

Background: Browsers check for a man-in-the-middle attack by verifying that:
a) remote site's certificate is signed by a certificate authority (CA) that
the browser trusts; b) the URL matches the common-name attribute (CN) in the
site's certificate.

So, for an attacker to get around this check, they need to: a) forge/spoof DNS
(relatively easy); b) get a cert signed by a CA the browser trusts with a
matching CN of the site to be spoofed (supposed to be relatively hard). (There
is also Extended Validation, I won't go into that here.)

Unfortunately, these days, browsers trust _a lot_ of CA's, either directly or
via chained certificates. Some of these chained certificates may be surprising
to you.

<https://www.eff.org/observatory>

~~~
tptacek
The good news is that this isn't a problem with the SSL protocol so much as it
is a problem with how the CA's and browser vendors have decided to configure
SSL. Which means you can fix a lot of this by removing certs from your browser
configuration.

------
shaggy
"Whenever you're sending sensitive information online—say, your credit card
number to Amazon or a message over Gmail—the content is encrypted before being
sent and then decrypted by the Web site you sent it to. (Sites using this
secure mode have URLs that start with "https," and browsers add a padlock icon
as well to demonstrate you're communicating securely.) Every vendor has its
own rules for how to scramble information so that only it, the intended
recipient, can decode it."

SSL does not encrypt content and vendors don't all ahve their own rules about
how SSL works. It's a standard. I really wish that journalists covering
technical matters would do enough research to explain things properly.

------
thyrsus
So long as Verizon happily issues new CAs to Etisalat, the following is a weak
measure, but for the moment: is there a way in various browsers to declare
that you don't trust specific CAs? I can't practically remove the Verizon
certificate (in my Certificate Authorities tab, I don't see Verizon, but I do
see GTE Corporation which was its previous name, so I'll guess they're the
same...), but could I declare "don't trust certificates containing _these_
certificates"?

~~~
kngspook
Yeah, you can usually delete certs, at least in third-party browsers, even if
they're built in.

I'm not sure if you can delete any of the OS's built-in certs ('cept maybe on
Linux); and I'm not sure I'd want to risk that. Verizon/GTE/whoever probably
authenticates a lot of really useful people too... (Which is a risk with
deleting the browser's root certs as well.)

------
devmonk
Interesting. Also interesting was that SSL has been hacked before, although
I've not heard much about it after then. For example:
[http://hackaday.com/2008/12/30/25c3-hackers-completely-
break...](http://hackaday.com/2008/12/30/25c3-hackers-completely-break-ssl-
using-200-ps3s/)

------
RiderOfGiraffes
Dup: <http://news.ycombinator.com/item?id=1640117>

Having said that - no comments there.

~~~
bensummers
Dup detection isn't terribly good here. Trailing /'s, Google Analytics link-
junk all aren't detected.

~~~
kngspook
The source code for the news.yc website is open source, right? We should patch
it...

~~~
RiderOfGiraffes
I'm pretty sure the live version has mods that aren't in the public version.
PG has said that he makes mods to improve various aspects, particularly things
like detecting voting rings and other such gaming of the system.

------
kenj0418
Was anyone else scared that the link was to goatse?

