

Broken Browsers Part Two: SSL - juliusdavies
http://blog.dreamhost.com/2009/05/28/broken-browsers-part-two/

======
tptacek
SSL/TLS does not work without certificates. In the absence of a "tie breaker"
for someone else's fake handshake data, the encryption it employs on the link
provides no more security than does LZ compression. And I'm supposed to buy
certs from these people?

See:

<http://news.ycombinator.com/item?id=277284>

Should CA processes be reformed? May-be so. I'd start with not allowing people
like Dreamhost to sell them. But that has nothing to do with how the browsers
enforce the SSL protocol.

~~~
juliusdavies
I'm curious what the poster of the awesome
[http://www.matasano.com/log/1749/typing-the-letters-a-e-s-
in...](http://www.matasano.com/log/1749/typing-the-letters-a-e-s-into-your-
code-youre-doing-it-wrong/) thinks of SSL on shared-host webservers!

Like probably 5,000 other people have SSH accounts into the same dreamhost
server where <http://juliusdavies.ca/> lives!

:-p

(This is not in anyway a response to tptacek's comment. Just a tangent.)

~~~
tptacek
Oh, sorry, I read this post like 10 times looking for something to rant about,
and nothing about it "stuck", so I didn't recognize it as a direct question.
Shows you how I think.

What do I think? Bad. I have a reason:

[http://www.matasano.com/log/460/modern-cpu-architecture-
thre...](http://www.matasano.com/log/460/modern-cpu-architecture-threat-or-
menace-the-case-of-branch-prediction/)

This is one example of the tens of different side channels that exist on
modern CPU architecture when you can run code _alongside_ crypto on the same
microarchitecture.

How serious are these problems long term? Nobody knows. The full
microarchitecture of an Intel or AMD processor isn't documented.

------
__david__
He's right the whole thing is a scam, but his solution is not correct. What
needs to happen is the domain owner should be issued a wildcard cert for their
domain when they purchase the domain. The public key goes in the DNS and is
itself signed by the registry (this prevents DNS spoofers from injecting valid
certs).

So if I bought example.com I'd get a cert for * .example.com and its public
key would sit in my dns somewhere signed by the master .com cert.

This would be more secure than what we have now _and_ get rid of all the
overpriced ssl resellers (really, you're charging me $100 a year for your thin
wrapper around openssl?).

~~~
oomkiller
Once DNSSEC is implemented, this would probably be a lot more secure and
easier to implement.

EDIT: I think there is an RFC for this already:
<http://tools.ietf.org/html/rfc4398>

~~~
tptacek
Or, you know, not:

[http://www.matasano.com/log/756/a-case-against-dnssec-
count-...](http://www.matasano.com/log/756/a-case-against-dnssec-
count-1-solves-a-non-problem/)

[http://www.matasano.com/log/772/a-case-against-dnssec-
count-...](http://www.matasano.com/log/772/a-case-against-dnssec-count-2-too-
complicated-to-deploy/)

------
juliusdavies
Punchline: Dreamhost is now selling 1-year browser-trusted SSL certs for $15,
but the domain has to be hosted @ dreamhost, and you also need a unique IP
($3.95/month).

Comments under the blog posting imply the certs contain CN=www.domain.com,
with Subject-Alt-Name=domain.com to get around the ever annoying "www." issue
there, but I haven't seen one for myself to verify.

No wildcard certs at this price level, sadly.

~~~
apgwoz
> but the domain has to be hosted @ dreamhost

From the post:

    
    
        You can use them with us or any other web host.
    

You do however need a unique IP regardless of where you're hosting it.

~~~
__david__
Actually you don't need a unique IP--You can have a bunch hosted on one IP, as
long as they all have unique port numbers (I host 4 or 5 ssl domains on my
server). I usually forward the non-ssl site to the appropriate port so no one
has to memorize the ugly number.

~~~
sokoloff
Not particularly a technical limitation, but a practical one:

Unfortunately, if your web site is intended to reach the masses, many of whom
sit behind restrictive firewalls that only proxy 80 and 443 for web traffic,
you need to be on ports 80 and 443.

------
quoderat
"I cannot understand why, after zillions of versions and dozens of years, no
browser implements forward and back correctly."

Preach it, homey!

I've been ranting about this same thing for years. Why is this fundamentally
broken in so many browsers?

------
brl
Wow, I haven't seen a <blink> tag in the wild since last century.

I stopped reading right about there.

