
Why isn't HTTPS everywhere yet? - yeukhon
http://webappsec-test.info/~bhill2/DifferentTakeOnOE.html
======
cm2187
Cost is going to be taken care of by let's encrypt.

I am surprised complexity of setting up SSL isn't mentioned in the article.

First the tools are complex to use, use various formats for storing keys that
are incompatible. In Linux you pretty much have to rely on cryptic command
lines. Windows is slightly simpler. And you need more tools to convert
certificates between the different formats (for instance using an IIS
certificate with FileZilla).

Then you have to deal with the complexity of the algorithms used, the fact
that chrome won't accept sha1 anymore, the fact that http2 is very picky in
the cryptographic methods used.

What is a best practice today breaks tomorrow. For instance the following
script written only a couple of years ago shows how to set up windows to get
an A on SSLLabs:

[https://www.hass.de/content/setup-your-iis-ssl-perfect-
forwa...](https://www.hass.de/content/setup-your-iis-ssl-perfect-forward-
secrecy-and-tls-12)

But with IIS10 / http2, this list of ciphers is incompatible with chrome. I
found a list that works here:

[https://code.google.com/p/chromium/issues/detail?id=529994](https://code.google.com/p/chromium/issues/detail?id=529994)

but I am sure it will break older browsers.

Etc, etc, etc. This is hard work. Until setting up SSL will be a simple box to
tick in IIS or a single setting to change in apache, only developers who
really care about security and are really motivated will deal with this shit.

~~~
Loic
The cipher list is effectively a big issue. When using the good old Sun
Fortran compiler, I was used to have a _-fast_ flag which would be smart to
detect the hardware and be as fast as possible while respecting the IEEE maths
(as far as I can remember).

I would love a _-secure_ flag to just use the most secure option of the
current version of the software even at the cost of X years of backward
compatibility at the tool/client/browser level.

For example for nginx instead of something like:

    
    
        ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS;
    

You would get:

    
    
        ssl_ciphers SECURE;

~~~
cm2187
Or they should package it in vestions. "TLS 1.3" would come with a standard
list of ciphers and other parameters. All you would have to do is tell your
system "Disable SSL3.0" "Enable TLS 1.3", etc.

Right now it feels like trying to fly a B747.

~~~
brians
That does happen! Enable TLS 1.2 only and you're in pretty good shape. TLS 1.3
will drop more bad stuff and add a bit more good stuff.

~~~
stealthyb
It definitely helps, but if you're trying to keep up with the latest security,
you'd be susceptible to Logjam (due to DHE-supporting ciphers in the default
TLS 1.2 list).

There's the Mozilla SSL Configuration Generator which helps with the madness,
but they still aren't keeping up with the latest recommendations.

------
r1ch
Still no mention about ads. Using HTTPS means you have to load ads over HTTPS
and a huge number of ad networks are not reachable over HTTPS and another
large number of assets / tags are hard coded to fetch HTTP resources. For any
ad supported website, HTTPS will cause a significant loss of ad revenue.

Given how long it's taking the industry to transition away from Flash I'm not
holding my breath about this being fixed any time soon.

~~~
manigandham
This is a big reason. Unfortunately the industry is full of old and/or poor
tech that is already fragile as it is.

All modern ad networks (like ours) are completely HTTPS ready but the
transition will be slow due to momentum with existing vendors.

~~~
lindx
Solution: block HTTP ads.

~~~
manigandham
Solution to what? Publishers still have to enable HTTPS on their sites and
they'll only do that once all the resources on the page are HTTPS compatible.

~~~
pmlnr
To this:
[http://idlewords.com/talks/website_obesity.htm](http://idlewords.com/talks/website_obesity.htm)

~~~
manigandham
While I agree with the gist of that article/presentation, it's more on the
silly side compared to many other more detailed and accurate pieces about the
growing weight of the modern web.

While blocking ads will help some (and certainly some ad providers have gone
way too far with their bandwidth/cpu requirements), the web is just a richer
media experience than before. The mainstream does not just want text and
80-90% of the page weight ends up being images, even on that article itself.
There are other advancements like HTTP/2 and modern CDNs and better image
formats like FLIF that will solve this problem much more effectively without
going back to a textual world.

Still don't see what any of this has to do with HTTPS encryption everywhere
though...

------
GeneticGenesis
Another big blocker is cost.

For example, one of the biggest CDNs in the world (I'm looking at you,
Akamai), charge dramatically more for delivering content over HTTPS. Let's say
you're delivering video content at scale, the difference between HTTP and
HTTPS delivery can be many millions of dollars a year.

But why not use a different CDN, say Cloudfront which prices the same for HTTP
and HTTPS?, well, simple, the same problem. Cloudfront is many times more
expensive than other CDNs at scale.

Really, we need to apply pressure to all CDNs to equal out their HTTPS pricing
(Its not just Akamai...)

~~~
jkire
I'd imagine HTTPS is significantly more expensive to host than plain HTTP, due
to the CPU requirements of the crypto involved.

~~~
fryguy
Maybe at the CDN level where there's lots of caching it's different, but for
regular hosting apps are primarily IO bound so it's essentially "free" to do
encryption. From [http://www.imperialviolet.org/2010/06/25/overclocking-
ssl.ht...](http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html):

> In January this year (2010), Gmail switched to using HTTPS for everything by
> default. Previously it had been introduced as an option, but now all of our
> users use HTTPS to secure their email between their browsers and Google, all
> the time. In order to do this we had to deploy no additional machines and no
> special hardware. On our production frontend machines, SSL/TLS accounts for
> less than 1% of the CPU load, less than 10KB of memory per connection and
> less than 2% of network overhead. Many people believe that SSL takes a lot
> of CPU time and we hope the above numbers (public for the first time) will
> help to dispel that.

~~~
brians
At the time that was written, only the frontends did TLS---remember, there
wasn't _universal_ strong encryption or authentication within Google's back-
end until after the Snowden leaks.

------
Ecco
I like the irony of that page being served over plain HTTP :-)

~~~
jkire
Ha! And HTTPS doesn't seem to work for me at all.

~~~
cmdrfred
[https://www.ssllabs.com/ssltest/analyze.html?d=http%3A%2F%2F...](https://www.ssllabs.com/ssltest/analyze.html?d=http%3A%2F%2Fwebappsec-
test.info)

    
    
        Assessment failed: No secure protocols supported
    

It fails spectacularly as well. No matter the quality of the content of this
article (and I'm one to agree with it), this sort of throws it out the window
for me. If you aren't able to manage a functioning version of the product you
are describing (especially in the lets encrypt era) you don't get to do a
technical article on said product.

------
dTal
I'm not convinced it's even a great idea until something is done about a) the
entirely broken CA trust model or b) mainstream web browser's entirely broken
attitude to that trust model.

~~~
zbuf
I am interested in (a). Recently I heard from a trusted source who works for a
popular CDN that some top levels CAs, who are trusted in my browser, are known
to be issuing certificates for domains which they have no authority to be
doing so, for the purpose of man-in-the-middle analysis by certain parties.
But that there is a reluctance to pull these certificates because that would
be like switching off portions of the web.

Is there any truth or more solid reference to this from those who are in the
industry and know more about these topics? Rather alarming if so.

~~~
glasz
just listen to security now [0]. it'll make your blood boil how, e.g.,
symantec fucks up over and over again. this industry is full of incompetent
idiots.

[0] [https://twit.tv/shows/security-now](https://twit.tv/shows/security-now)
(episode 532 is particularly revealing)

~~~
zbuf
Thanks, interesting to hear. If I heard correctly this is a case of
incompetence -- which is certainly a problem. Though the information I heard
was about lesser-known CAs granting certificates to enable some kind of
snooping.

It seems that a problem with the current implementation of SSL is that it
conflates the requirement for encryption with that for identification.

Knowing that "Symantec thinks this is google.com" has limited benefit to me;
I'm happier with the idea that "This is the same google.com you visited
before".

------
Zarel
In addition to ad revenue issue r1ch mentioned (a friend of mine told me HTTPS
ads provided less than half the revenue HTTP ads provide), there are a few
other things I've encountered while working on HTTPS support:

\- More ad network misbehavior: the last time I checked, a lot of HTTPS ads on
AdSense would take up 100% CPU and lag the browser, because it would try to
request an HTTP resource and fail in an infinite loop

\- More failed connections: just two weeks ago, a Firefox update made HTTPS
sites inaccessible on computers with certain HTTPS-scanning antiviruses
installed:
[https://news.ycombinator.com/item?id=10854629](https://news.ycombinator.com/item?id=10854629)

\- Browser bugs: Chrome doesn't let you HTML5-drag-and-drop data-URIs from
HTTPS: [https://github.com/Zarel/Pokemon-Showdown-
Client/commit/53a1...](https://github.com/Zarel/Pokemon-Showdown-
Client/commit/53a1..).

\- Warnings when embedding HTTP images: Users often embed HTTP images in
community sites like forums, chatrooms, etc, which cause warnings in Firefox
and make Chrome remove its "secure" designators

\- Annoyance: I tried to get a Let's Encrypt certificate recently. My server
runs Node, and it doesn't serve arbitrary files from a directory (it's a
WebSocket server) so the webroot method wasn't possible, so I actually had to
stop the server and reconfigure the firewall not to redirect ports 80 and 443
to get the certificate.

`letsencrypt-auto` also gives very cryptic error messages: apparently "Correct
zName not found for TLS SNI challenge. Found" means "please use `sudo -H`".
And the standalone verification failed for an unknown reason, but at least I
eventually got the Apache verification working. And I'm going to have to go
through all this again in three months...

~~~
majewsky
Regarding the "Annoyance" bullet point, you might have a better time if you
put an Apache or nginx in the front (on ports 80/443), have it serve the acme-
challenges statically and proxy_pass everything else to Node running on a high
port. TLS handling would then happen in the frontend server only.

Regarding the "please use sudo" issue, it's very much possible to run the
letsencrypt client as a non-root user if you set your filesystem permissions
carefully. Here's the letsencrypt configuration for a private webserver of
mine: [https://github.com/majewsky/system-
configuration/blob/master...](https://github.com/majewsky/system-
configuration/blob/master/holodeck-damogran.pkg.toml#L454-L575)

~~~
nailer
Adding an entire piece of server software for soemthing like node or phoenix,
just to answer an HTTP response is overkill. If you want to use LE, make a
node client to get the certs and do the renews and shove it on npm.

------
Spooky23
A: It doesn't solve any problems that people think they have, and causes
others.

------
kefka
Im not able to use SSL certs on all my endpoints. I have to use self-signed
certs. That's because many of my machines are on TOR hidden services.

The CA-CERT won't allow any certs for .onion unless you buy at exorbitant
price an EV2 cert. And that especially means no free certs.

So I do use self-signed because I want end to end crypto (and the next-to node
can see data). Of course my browsers throw a fit, but alas I am indeed secure.

... but I want an .onion cert authority by LetsEncrypt and first-class network
routing for all .onion addresses in Linux via /etc/resolve.conf

~~~
Integer
I always thought .onion sites are end to end encrypted. "The rendezvous point
simply relays (end-to-end encrypted) messages from client to service and vice
versa." according to [https://www.torproject.org/docs/hidden-
services.html.en](https://www.torproject.org/docs/hidden-services.html.en)
There's even a ticket to add a padlock to indicate this in TOR Browser
[https://trac.torproject.org/projects/tor/ticket/8686](https://trac.torproject.org/projects/tor/ticket/8686)

~~~
kefka
My understanding was that the connection prior saw the cleartext of the final
destination's packets.

SSL was the way to make sure that end to end was encrypted so that nobody
could read the data (mainly login/password info).

I think the only way to see is to be part of the tunnel architecture and see
if my thoughts are right or wrong.

~~~
pfg
What you're saying is correct for connections from tor to cleartext sites.
Hidden services are end-to-end encrypted. I'm not sure which cipher tor uses;
maybe modern browsers are better in that respect.

------
ac29
Something that no one has seemed to mention: it doesn't work on shared
hosting, it requires a static IP. For small sites, the additional cost of
moving to a plan that supports SSL and has a static IP, this could be a big
cost.

~~~
Zarel
It doesn't require a static IP; you can use SNI to use HTTPS on a shared IP:

[https://en.wikipedia.org/wiki/Server_Name_Indication](https://en.wikipedia.org/wiki/Server_Name_Indication)

SNI was already been mentioned an hour ago, too:

[https://news.ycombinator.com/item?id=10928036](https://news.ycombinator.com/item?id=10928036)

~~~
ac29
Interesting, I hadn't heard of that. Perhaps I should make a correction -- on
the webhost my small business uses, purchasing a static IP is required for SSL
support. I was under the impression this was a technical limitation, but I was
apparently wrong.

~~~
pizzeys
Shared webhost here: It's one of those complicated part-technical, part-user
education issues.

Technical: SNI breaks older browsers (IE on XP, older mobiles). Also requires
a modern (ish) OS on the server, if using CPanel, which like, every shared
host in the world is pretty much.

User Education: Explaining exactly which clients will be broken is hard, etc.

#2 is basically gone now, because the users who would be broken are broken by
the removal of SSLv3 and insecure crypto anyway - so we've now already killed
them and can SNI without having to explain anything complicated to the user.

------
bobfunk
We just launched support for free SSL on all our plans at
[https://www.netlify.com](https://www.netlify.com), doing what we can to help
getting HTTPS everywhere.

Won't help on mixed content or broken ad providers, but at least give people a
place to put a project on a custom domain for free with HTTPS :)

~~~
notfoss
What is the Full SSL feature offered by you? From what I understand it means
supporting weaker ciphers apart from SSL and older TLS versions. Is that the
case?

~~~
bobfunk
The full ssl feature means skiing a fallback certificate for non-SNI capable
browsers.

Internet explorer on windows XP and Android 2.3 doesn't support SNI based ssl
and our full ssl solution assures that even these older browsers can access
the site over https without any warnings...

------
Yaggo
HTTPS (in the current form) adds a dependency on external authority. This
breaks the very fundamental principle of the web.

~~~
pmlnr
[https://letsencrypt.org/](https://letsencrypt.org/)

~~~
Yaggo
Still an external authority.

~~~
pmlnr
Sure. And why would I trust anyone who says I'm a good guy, trust me, without
any confirmation?

------
wodenokoto
When I lived in China I was pretty happy the https movement hadn't won yet.
Sites that forced me on a secure line were basically useless.

The great firewall doesn't appreciate encrypted connections, and will usually
grind to a halt, when deciding if it will let you get the content.

~~~
drdaeman
Isn't it the contrary. If Internet would be practically unavailable in China
except for domestic resources, due to every single server using TLS for
absolutely anything — would Great Firewall survive?

~~~
wodenokoto
Yes, it would and is. Remember that all major webservices that take up most of
peoples online time in the US and Europe is already banned in China. There is
no Netflix, Hulu, Facebook, Google, Youtube, twitter, snapchat, Whatsapp
working at all or reliably within the firewall.

The quality of the content inside the firewall is good enough for the majority
of the population not to care the least about what is happening on the web
outside the firewall.

The good viral videos and memes get translated and spread on local services,
and plenty are already created within.

------
programminggeek
Three obvious reasons...

Cost to the end user $10-200/year - even more on Heroku($20/month).

Configuration/Setup sucks - seriously you are supposed to run a bunch of unix
commands, copy something to a server, and the whole process isn't user
friendly.

Limited end user benefit - A business owner and user up until recently hasn't
thought much or cared much about information security outside of online
purchases.

Until it is cheap/free and once click easy, it won't be everywhere.

~~~
0_00_0
"Cost to the end user $10-200/year"

What? How have you not heard of Let's Encrypt by now?

~~~
drdaeman
There are some issues that are still prevent using their certificates in
production¹. For example this one prevents Windows XP clients (not just IE,
but anything that uses system X.509 libraries) from connecting:
[https://github.com/letsencrypt/letsencrypt/issues/1660](https://github.com/letsencrypt/letsencrypt/issues/1660).

Still there's WoSign (free for everyone) and StartSSL (free for non-commercial
use).

____

¹) Only where 3-5% of more obscure clients still matter.

------
x3sphere
Ads are one reason, some big networks still don't fully support HTTPS so
publishers get a reduced ad pool (and potentially lower earnings as a result)
if they switch over to HTTPS.

------
ck2
Because many websites are ad supported and few ad networks have https ads
ready and configured properly, so they do not display.

Even on adsense, inventory drops for a https-only website.

------
jamespo
I work for a large bank and a lot of "lesser known" SSL sites (eg blogs that
have a cert) are just straight off blocked by the bluecoat proxy.

------
xroche
"Why isn't HTTPS everywhere yet?": Because it makes absolutely no sense for
the vast majority of online content. Email in https ? Sure. Reading news sites
in https ? Accessing RFC in https ? My favorite online recipe site in https ?
A total waste of money and CPU.

Oh, and sure, the problem has been "solved" for few geeks using the latest
browsers accepting let's encrypt certificates. Sure.

~~~
pdkl95
> Because it makes absolutely no sense for the vast majority of online
> content.

So you use postcards for most "the vast majority" of your snail (postal
service) mail, right? Because _envelopes_ [1] make "absolutely no sense"?

Besides the security issues that have already been mentioned of someone
_modifying_ the content as a MITM - something which ISPs are already doing[2]
- this is really just another version of the "If you have nothing to hide..."
falacy. You do have things to hide, because you shouldn't let every node that
handles your traffic compile a database of your browsing activities.

[1]
[https://www.philzimmermann.com/EN/essays/WhyIWrotePGP.html](https://www.philzimmermann.com/EN/essays/WhyIWrotePGP.html)

[2] e.g. "X-UIDH" and the various ISPs that inject javascript for various
reasons.

~~~
brians
Actually, yes. The vast majority of snail mail I receive is open catalogs and
other junk mail. Its content is entirely public.

------
thehairyone
a2enmod headers

echo -e "ServerSignature Off\nServerTokens Prod" >> /etc/apache2/apache2.conf

/etc/init.d/apache2 restart

openssl req -new -nodes -keyout webappsec-test.info.key -out webappsec-
test.info.csr -newkey rsa:2048

cat webappsec-test.info.csr

 __ __Register here:

[https://www.startssl.com/](https://www.startssl.com/)

Copy and paste csr...

cat Domain_cert.pem CA_root.pem

[https://mozilla.github.io/server-side-tls/ssl-config-
generat...](https://mozilla.github.io/server-side-tls/ssl-config-generator/)

====>

A+ on

[https://www.ssllabs.com/](https://www.ssllabs.com/)

 __ __ __ __ __ __ __ __ __ __ __ __ __

Now? What 's so hard about that?

I guess if you're using EC2 and Ubuntu on your server... ehhh...

~~~
duskwuff
Why use StartSSL, when Let's Encrypt will give you an equally good certificate
(with more flexibility on SANs!) with less hassle?

~~~
thehairyone
No, it doesn't.

Lets Encrypt certs are equivalent to self-signed certs.

No hassle ==> broken shit.

~~~
unethical_ban
No, you are incorrect. At the moment, their certs are cross-signed, and I have
tested my site with multiple browsers. It works.

~~~
thehairyone
The cross sign is too far up the chain.

If you cross sign a self-signed cert what do you get?

A Let's Encrypt Cert.

Domain Ownership is not the same as file ownership.

~~~
thehairyone
Of course the cross signed cert works!

That not the point.

The cross signature is worthless if the signed cert beneath it is self-signed.

If Identrust cross signed self signed certs, the self signed cert would be
trusted too... and it would "work" in all browsers...

Coly Tarry Frap Tarts! you're daft.

Here try this:

1\. Setup a domain with an MX record that points off domain and a dmarc
p=reject record...

2\. Try to get a cert from _any_ CA other than Lets Encrypt without answering
any emails sent to the off domain MX.

...

Then... install Lets Encrypt... bam-o! Cert heaven!

It's self-gawd-damn-fing-signed.

~~~
thehairyone
@pfg:

I know exactly how CAs work. I've built several.

Wosign does not issue a cert without an email verification.

You can look on their website. There's a nice big box to enter an email
address to verify your domain and get the free cert.

Sorry -- "Let's Encrypt" with file verification is not DV.

It's just not DV. Simple really...

And it's gonna break the web. Like netlify up there a few post... using
rackspace and "Let's Encrypt". ehh. The first few months will probably be fine
and then everything is gonna tank.

Until the smart realize that ACME is fine -- as long as you remove the "or
file verification" text.

~~~
jcrites
You seem to think that a certificate authority is obligated to verify
ownership of a domain by email (for DV certs). You are mistaken, and that's
not the case. The mechanisms supported by _Let 's Encrypt_ to authenticate
domains are _just as good_ as email verification.

If you've been involved in a CA, then you should be familiar with the CAB
forum baseline requirements for Verification Practices.
[https://cabforum.org/wp-
content/uploads/BRv1.2.3.pdf](https://cabforum.org/wp-
content/uploads/BRv1.2.3.pdf)

> For each Fully-Qualified Domain Name listed in a Certificate, the CA SHALL
> confirm that[] the Applicant[] has control over the FQDN by: [...]

> 4\. Communicating with the Domain’s administrator using an email address
> [...] ‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’
> [...] followed by the Domain Name[];

> 6\. Having the Applicant demonstrate practical control over the FQDN by
> making an agreed-upon change to information found on an online Web page
> identified by a uniform resource identifier containing the FQDN

> 7\. Using any other method of confirmation, provided that the CA maintains
> documented evidence that the method of confirmation establishes that the
> Applicant is the Domain Name Registrant or has control over the FQDN to at
> least the same level of assurance as those methods previously described.

The approach used by _Let 's Encrypt_ meets this standard (of which email is
just one of several options), and the methods they use are just as secure as
using email. They specifically offer approach 6. above, which they call Simple
HTTP, as well as other approaches that comply with 7. as outlined in
[https://letsencrypt.github.io/acme-
spec/#rfc.section.7](https://letsencrypt.github.io/acme-spec/#rfc.section.7)
Involving email in the verification process makes certificate provisioning
harder to automate and adds no additional security.

