
HTTPS is more secure, so why isn't the Web using it? - zoowar
http://arstechnica.com/web/news/2011/03/https-is-more-secure-so-why-isnt-the-web-using-it.ars?utm_source=rss&utm_medium=rss&utm_campaign=rss
======
fierarul
'The web' isn't using HTTPS since SSL is a nice yearly 'tax' on the domain
owner.

It seems to me we have a nice centralized monopoly here with the existing
Certificate Authorities (most US-centric) for something as decentralized as
the internet.

Why can't the domain name registrar give me a SSL cert for free? I mean, if I
did buy a domain name, and I'm able to change the records, it's pretty clear I
own the thing. Certificate info should just be a DNS record imho.

Regarding identity checks, there are other stupidities I see here: for
example, my company has to send monthly/yearly papers to the government
entities (some of which get publishes into some official government papers).
Why can't I publish my public key there?

I mean, if anything, it's very bureaucratic to do anything involving public
institutions so each paper is stamped, checked, etc.

I would trust more a local clerk to check for identity then some US guy that
has never in his life actually seen a deed of incorporation for a Romanian
entity.

So, yeah, I would love to have my site with HTTPS and to sign all my JARs and
emails but until this becomes more sane or my customers actually start
demanding it, I'm not going to waste money on that.

~~~
JonnieCache
_> Why can't the domain name registrar give me a SSL cert for free?_

<http://www.startssl.com/> will give you a free class one SSL cert that works
in all major browsers. They will also sell you a class 2 cert with wildcard
support for $49 a year. These can cost $800+ in other places IIRC.

They are trying valiantly to destroy the entrenched price structure of the SSL
cert market and I wish them the best of luck.

~~~
mooism2
Their website says their certs work in all major browsers, but I can't find
anywhere where it says which versions of those major browsers it works with.

E.g. it works with Internet Explorer. Does that include IE6? They don't say.

~~~
JonnieCache
They're free, why not try it and find out? ;)

But yes, as far as I remember, they do work on IE6. The root certs dont really
change between browser versions I think, its more a matter of the the
different vendors.

~~~
yuhong
To be more precise, IE uses the SSL libs built-in to Windows since 2000. As a
result the list of trusted root CAs is built-in too. MS added StartCom to the
list in 2009.

------
nate
I was doing some load testing on a new project of ours and noticed that I
couldn't break 50-60 reqs per second sending all the requests through stunnel-
haproxy or apache-haproxy to a cluster of app servers that should have handled
about 200ish reqs per second. This wasn't a problem if the traffic wasn't
encrypted. Didn't seem like a CPU bottleneck with the machine doing the load
test measurements either.

So I did some digging. And noticed that <https://encrypted.google.com> uses
RC4_128 as a cipher. You know what Bank of America uses too? RC4_128. RC4
happens to be a much faster cipher.

RC4 has gotten some bad press as it was used in WEP encryption and was
cracked. But I believe it was because their RC4 implementation had a flaw
rather than RC4 at 128 bis being a terrible choice for encryption? I'm not
positive and would love to hear your input.

I switched our load balancer to make sure we were using RC4_128 instead of
AES_256, and bam I had 3-4 times more throughput of encrypted requests going
through just fine.

~~~
mukyu
The attacks used against RC4 as used in WEP are not applicable to RC4 as used
in TLS connections. If you do not use related keys and discard at least the
first 256 bytes, RC4 is fine. It is not that they implemented RC4 incorrectly,
but that they did not account for its known weaknesses.

------
DrStalker
If browsers would be happy to allow users to a site with a self-signed SSL
certificate, which is far more secure than HTTP, then I'd be happy to put in
the extra time and effort to ensure 100% of communications occured over HTTPS.

Until then it's extra time, effort and cost to offer something that most users
do not understand and do not care about.

~~~
mukyu
A self-signed cert provides effectively zero protection. You have no guarantee
of the identity of the site and there is no confidentiality in your traffic.
Key continuity (the only assurance you have that the cert might be legit) is
not effective on the web, where you are likely to interact with hundreds of
unknown hosts.

If browsers do not throw big warnings at self-signed certs it is trivial to
impersonate even sites that do have real certificates. The user sees a lock
icon and thinks they are secure, but they are sending their credit card to
someone other than Amazon.com. This is slightly fixed by EV certs, but there
is still a large user training issue.

~~~
jedsmith
> A self-signed cert provides effectively zero protection.

From the other end.

I had this debate with someone in person, and they tried to tell me that since
you cannot trust the other end with a self-signed there is no point in
protecting your traffic from eavesdroppers on the open AP. That makes no sense
to me, but he was passionate enough about it that I let it go. He never could
tell me _why_ , so I invite a more learned HNer to complete his argument for
him and persuade me.

My take:

There's a difference between _identity_ and _encryption_ , and I think warning
users about a site that wants encryption but doesn't necessarily want or need
identity is a bigger user-training mistake than anything else browsers have
ever done.

Perhaps the lock was the problem there; in that case, if I offer a self-signed
certificate, perhaps the better UI experience would be to inform the user in
that "Page Info" that their connection is encrypted, but they have no idea if
the other end is who they say they are -- and don't bless the page with a
lock, bar, anything. The entire construction of <https://> needing to imply
both _encryption_ and _identity_ doesn't make sense to me, as I see them as
distinct concepts. One does not necessarily imply the other, but browsers make
it so.

Maybe this is inherent to SSL/TLS itself and I'm the off-base one, but
logically it makes sense to me.

~~~
mukyu
There are not many cases where you can read traffic, but not intercept/inject
your own.

All you need to do is generate your own cert for the site and the user will
encrypt their traffic _to you_. This is why the lack authentication means that
no confidentiality is provided.

~~~
rwmj
You just ensure the browser warns you if the self-signed certificate
_changes_.

It works fine this way for ssh.

~~~
arethuza
Out of interest, if you are warned that a site's SSL certificate has changed,
what steps would you take to confirm the authenticity of the new certificate?

~~~
ezyang
You use the same model as SSH: give a big warning with klaxons "Warning, this
site's SSL certificate has changed, it is possible that you are being actively
attacked" and then force the user to dig into an text file and manually remove
the offending memorized entry (no prompt for saying "Ignore and carry on").
The hope being that an inexperienced user would find someone more competent to
help them out.

There are loads of ways this could go wrong (the phishing website earnestly
telling the user that they "changed" their SSL key and that you need to follow
these simple steps to "fix" your browser; the initial contact being the bogus
website; the huge loss of traffic if your SSL key legitimately changes and
you're not prepared; you need to deal with revocation).

------
kennet
I have a silly, fictional view of the future: That every website will be HTTPS
by default, and instead of Firefox/Chrome/etc using a "green" bar to tell a
secure website, it will not say anything, but will display big red warnings
when a website is not secure.

~~~
jedsmith
And we'll all have muscle memory to add the exception through the browser's
four-step "I know what I'm doing" UI.

~~~
drzaiusapelord
In Chrome and IE its one or two clicks. I don't know why people tolerate
Firefox's silly "ZOMG THIS SSL CERT MIGHT BE WRONG" 90-click UI. Joe Averge is
still going to run through the clicks. Badgering the user with more prompts
has been shown to not increase security and only frustrate power users.

------
listrophy
From the article, it's not so much the TLS protocol that allows SSL on virtual
hosts, it's specifically the Server Name Indication (SNI) TLS extension. And
every major browser version supports SNI except IE6 (arguably not major
anymore) and any IE on XP (except maybe IE9?).

~~~
jedsmith
IE9 will never run on XP, so you're right, just not in a way you expect.

~~~
listrophy
I thought that might be the case, but I figured I had already hit my limit on
parenthetical phrases, so I didn't bother investigating.

------
yason
I'm strongly in favor of encrypting the channel even without signed
certificates. A self-signing certificate doesn't _authenticate_ the session
but it can be used to later verify that the other end hasn't changed.

It's much like bumping onto someone at the gym frequently but not really
knowing their name or who they are. You can still trust that he's the _same
guy_ , sans having had a facial plastic surgery.

Sending passwords over plaintext http is just stupid. To mount a man-in-the-
middle attack you actually have to _do something_ and position yourself
between the two ends, not just listen to the passing network traffic.

So, you might log on to Twitter at home (a relatively safe connection) and
receive their public key and then use that to communicate with Twitter again
later in public wifis or among middlemen at the airport. The browser would
refuse to connect if the key doesn't match, much like ssh will complain if the
host key fingerprint has changed (and require you to do manual purging of your
known_hosts file).

Gmail is the only one where you can tap "Always use https" on. To Facebook you
can connect with <https://facebook.com> but I don't know whether any auxiliary
or Ajax/XMLRPC connections will use that.

~~~
chrisbolt
_I'm strongly in favor of encrypting the channel even without signed
certificates. A self-signing certificate doesn't authenticate the session but
it can be used to later verify that the other end hasn't changed._

Because it's comforting to know that you handed over your private information
to a man-in-the-middle and nobody else.

~~~
pyre
Errr... Are we advocating HTTPS everywhere? Or just when it's time to transfer
private information?

When I want to read an essay on some random website, to I _need_ to now that
the website owner is who they say that they are? Isn't self-signed HTTPS
better than just plain old HTTP? Or is it better that we _only_ use HTTPS for
a select few sites that aren't self-signed and HTTP everywhere else?

~~~
chrisbolt
If you're not transferring private information, why does it matter if it's
encrypted? Either you care if someone can eavesdrop or you don't.

~~~
fierarul
The whole online presence might be something that some regard as private since
reading a given URL might be as private as a forum password or card info.

But 'either you care or you don't' seems too inflexible to me.

For example, I might care that my bank has a certificate signed by a CA.

But for some usergroup's online forum, a self-signed certificate is enough.
Sure, we might get some MITM but the barrier to this is so high and the
relative importance of the online forum so low, it seems an adequate trade-
off. I'd say there's a higher chance of the server hard drive failing than to
see an actual MITM attack on a given niche server.

But overall, as I've said in another message here, I see this whole
centralized design as flawed and much too expensive. Certificate info should
be a DNS attribute.

------
kogir
Why can't I add my site's certificate as a DNS record, use DNSSEC and be done?

I don't want to give Symantec (owner of Verisign) money or trust to do
something I can easily do myself.

~~~
asharp
because DNSSEC isn't required.

As an example, if i mitm your dhcp request, i insert myself in as your dns
server and gateway and i just say that DNSSEC isn't enabled for this domain.
You have to trust me, and I can give you a MITM'd page.

Similarly dnssec uses a very similar model. You need somebody to sign that
your record is valid which is roughly the same as somebody signing your
certificate as valid. They are both a chain of trust, they just differ
slightly in implementation.

I do agree with you that using dnssec makes more sense then our current
system.

------
tghw
_The real problem, according to Lafon, is that with HTTPS you lose the ability
to cache._

I'm fairly certain this is false, unless they're talking about proxy caching.
Normal browser caching works equally well in HTTPS as it does in HTTP.

~~~
jedsmith
The leading browsers were fairly stubborn on caching SSL resources for a while
-- specifically to disk -- but (I think) most of them now obey the magic
words:

    
    
        Cache-control: public
    

Some data here: [http://stackoverflow.com/questions/174348/will-web-
browsers-...](http://stackoverflow.com/questions/174348/will-web-browsers-
cache-content-over-https)

I'm interested in what the state of this is, myself, but I know that one of IE
9's improvements was HTTPS conditional requests.

------
kinofcain
What I find as slightly amusing is that the major web browsers will throw up
all sorts of fancy, scary warning messages if you're hitting a site with an
expired or invalid certificate, but they don't say a darn thing when you hit a
site over http.

I understand that lying about your encryption is potentially a bigger deal
than not having any at all, but still.

------
bitskits
I have a feeling it has more to do with the sharing of cookies and tracking
code than anything else. Once everything is <https://>, marketers aren't able
to share information across sites, and although the internet is made of cats,
those cats need their money.

------
benjoffe
> You wouldn't write your username and passwords on a postcard and mail it for
> the world to see, so why are you doing it online? Every time you log in to
> Twitter, Facebook or any other service that uses a plain HTTP connection
> that's essentially what you're doing.

I'll be honest, I didn't read any more of the article after this totally false
statement in the intro. Facebook and Twitter both use https for login (they
are http pages that submit to a https endpoint that redirect to http, that way
https is used for authentication but never appears in the url).

~~~
kinofcain
Sort of. Twitter and Facebook still serve their home pages as HTTP and provide
a login form that posts over HTTPS.

The problem is that I can do a MITM attack on the unsecured home page and put
my own script in there that siphons off the user's password when they click
the submit button.

So the HTTPS-posting form prevents the eavesdropping case, but not the man-in-
the-middle case.

That's how the Tunisian government was harvesting their citizen's facebook
logins:

[http://www.thehackernews.com/2011/03/exposure-how-does-
tunis...](http://www.thehackernews.com/2011/03/exposure-how-does-tunisian-
government.html)

------
eapen
Disappointed to see that this author doesn't really understand the issue he is
writing about. The Firesheep tool would actually pick the cookies sent over
HTTP rather than the username/password which was sent securely (in most
cases). Also, as others have mentioned, it is possible to have an SSL cert
installed on Virtual hosts. Dreamhost offers an option for as little as around
$3-4 a month to have an SSL cert for a site.

Sometimes, I wish I could downvote an article on HN.

------
jeza
Living in Australia, I can tell you the main reason caching is so important is
because our main telco decided to charge by megabytes of usage. Back in the
days when most of us were stuck on dialup, they were charging $0.18 a
megabyte. At least the slow speeds limited the damage, though downloading a
600MB would still have cost a ridiculous $108. Meanwhile the rest of the world
hadn't even though of charing such tariffs for internet usage. Of course once
you have one company setting the standard then their competitors all follow
suite.

While things have improved tremendously since then, broadband plans are still
based around download and sometimes even upload usage. At least now you're
looking at something more reasonable like $50/month for 50 gigabytes a month
of included download usage. So originally caching would actually save you
serious money (unfortunately ISPs rarely passed on these savings to customers
if they used their proxy server). Though nowadays it's less important as long
as the websites you visit are responsive. Granted you're always going to have
some kind of client side cache.

------
mopoke
> Perhaps the main reason most of us are not using HTTPS to serve our websites
> is simply that it doesn't work with virtual hosts.

That's a bit confusing. They mean when multiple sites share the same public
IP. You can run SSL on a "virtual host" (i.e. a host running as a VM rather
than on bare metal).

Also not mentioned is the general increase in server load by having to
encrypt/decrypt all traffic. (or the additional cost of investing in a
dedicated layer to do that for you).

~~~
streeter
It is actually possible to serve multiple virtual hosts from the same IP
(<http://en.wikipedia.org/wiki/Server_Name_Indication#The_fix>).

The first technique is called Sever Name Indication, which is a way to specify
a virtual host with TLS (https) negotiations by sending the virtual domain as
part of the TLS negotiation

The second method is a specification that introduces the subjectAltName field
which allows one cert to be used across multiple subdomains (for things like
wildcarding). This would make it really easy to do organization-based
subdomains with TLS encryption.

There are limits to which browsers and which servers can do it. It requires
IE7 and up (not on XP though), and basically all recent versions of other
browsers.

Edit: noted that IE on XP doesn't work.

~~~
duskwuff
SNI doesn't work in IE7 (or IE8) if you're running Windows XP. This ends up
leaving a sizable chunk of users unable to use it.

------
PHPAdam
Its due to SSL Tax should be included free with every IP. IMHO.

------
known
HTTPS - HTTP = 3 Seconds

