
Why No HTTPS? - iafrikan
https://whynohttps.com
======
repsilat
When I'm on free airport wifi they'll often limit the session to half an hour
and then start MITMing your traffic to try to bounce you back out to the sign-
in page to agree to the terms and conditions again. When that happens, the
redirect won't work if you're trying to browse to an HTTPS URL. Worse, for
many sites you can't tell your browser to "just go along with the MITM"
because of HSTS.

So in airports I rack my brain for a website that might serve content over
HTTP, not HTTPS. Alas, they're getting harder to find, and it's getting harder
to keep those airport wifi sessions going. I half considered registering
"alwaysinsecure.com" or "alwayshttp.com" so I could reliably find one... Now
I'll probably just use qq.com, it's short and easy to remember.

EDIT: Thanks all :-)

~~~
glenjamin
[http://neverssl.com/](http://neverssl.com/) is what you're looking for here.

~~~
bogomipz
Interesting. What the prescription here - to simply use
[http://neverssl.com](http://neverssl.com) in order to see if you need to re-
authenticate to the captive portal? Is that correct?

~~~
pohl
That's my interpretation of what [http://neverssl.com](http://neverssl.com)
says. (Did you click-through to read it?)

------
rurcliped
I have public content that I'm willing to share over the web. To offer it over
HTTP, I only need a few thousand lines of code on top of TCP. It's realistic
to prove that that code has no memory-safety problems. To offer it over HTTPS,
I need to add tens of thousands of lines of extra code related to
cryptography. No existing implementation is known to be correct. The popular
implementations don't have a strong history of code quality. It's completely
reasonable to expect that, over time, new vulnerabilities will be found that
will allow attackers to read or write to unintended memory locations on my
server.

I totally understand that, by adding a popular but historically unsafe
cryptography implementation, I can help web clients to avoid MITM shenanigans
while reading my content. MITM indeed is a problem. But, I'm not willing to
make that my problem. The vast majority of my customers don't experience MITM
data modification while reading my content. The vast majority of my customers
wouldn't care if the whole world knew that they have read my content.

Perhaps in the future, code for all the required cryptography layers will be
just as provably correct as code for reading the cleartext HTTP protocol. When
that day comes, I will add HTTPS. Not before.

~~~
bfred_it
I don’t follow.

1\. You don’t have to write any code to use HTTPS, it has already been
written.

2\. Are you saying that since HTTPS isn’t perfectly secure you’re gonna use
the definitely insecure HTTP? What kind of logic is that?

~~~
xamuel
From a purely selfish perspective:

HTTP worst case: your reader is harmed.

HTTPS worst case: you yourself are harmed (e.g., if someone finds a zero-day
in a cryptography library and uses it to run arbitrary code on your server)

~~~
UncleMeat
Yeah because nobody has ever found rce bugs in other parts of the http server
infra. The only way people get rce on your box is by exploiting tls libs.
Right.

~~~
xamuel
HTTP is simple enough I can literally create a barebones semi-compliant HTTP
server from scratch. If all it has to do is serve some static pages, I can do
this in ~1000 lines or less. I don't need any infrastructure beyond basic
TCP/IP. Can't say the same about HTTPS.

~~~
comex
I'd say you should be counting the lines of code needed to implement TCP/IP –
as well as DHCP, ARP, Ethernet, maybe DNS, and anything else I've forgotten
that your server needs to speak. Consider lwIP, the most common implementation
of those protocols on microcontrollers: it's meant to be minimalistic, but
it's still some ~35,000 SLoC, not including tests. For comparison, a
minimalistic implementation of TLS is Amazon's s2n, which is ~12,000 SLoC.
Adding s2n to lwIP would only represent an increase in code size of about one
third.

Of course, a more typical HTTP/HTTPS server will be using the Linux kernel for
networking (with some userland bits for DHCP and DNS), and OpenSSL for TLS –
overall representing multiple orders of magnitude more code. But I suspect the
proportion between TLS and non-TLS would be somewhere in the same ballpark,
depending on how you count.

The problem is that on Linux, the TCP/IP stack is in-kernel, universal for
everything on the system, and overall unobtrusive – it mostly 'just works' –
while OpenSSL is in userland, has an unwieldy API and unstable ABI, can be
linked in many different ways, requires a lot of configuration, and is overall
a pain in the neck. So as a developer, the complexity of TLS weighs heavily on
you, while the complexity of TCP/IP is something you can largely forget about.

Personally, I think TLS adoption would have been quicker if it had been
implemented in the kernel and it just became a switch you could flip in the
socket API; something like:

    
    
        socket(AF_INET, SOCK_STREAM, PF_TLS)
    

But for better or worse, that's not how things panned out.

------
air7
It's worth noting that HTTP->HTTPS redirect is, in some sense, game-over
already. A malicious actor upstream can mitm by blocking the redirect and
providing an HTTP version to the client while communicating HTTPS to the
server. sslstrip is one implementation.

~~~
dwheeler
A quick solution that solves many cases is to also use HTTP Strict Transport
Security (HSTS), and declare it for at least a year. Then once the user visits
the site (say from home) and gets the HSTS header, later visits in that time
will always use HTTPS. This solves the problem in many cases.

The best solution is to get your site into the HSTS preload list. You can do
that here: [https://hstspreload.org/](https://hstspreload.org/) \- this adds
the site to the Chrome list, and most other major browsers (Firefox, Opera,
Safari, IE 11 and Edge) have an HSTS preload list based on the Chrome list.
Once that happens and the browser updates, users will always use https, even
if they ask for http.

~~~
CydeWeys
Even simpler, just use a domain on an HSTS-preloaded TLD, like .app. And stay
tuned for more options coming soon ;)

------
sonnyblarney
The 'web' is kind of for the commons, but HTTPS is just a few steps away from
being 'easy'. The steps required are frankly just a little too weird and ugly.

Most people making web sites, even many devs, don't necessarily want to, or
have the wherewithal to deal with SSL.

Setting up SSL on AWS recently was a monster pain the rear for our little
nothing project site, granted a lot of that was AWS oriented.

It needs to be easier, if it were easy, everyone would be doing it.

~~~
lucideer
> _many devs, don 't [...] have the wherewithal to deal with SSL._

I can buy this for a non-dev clicking "Install Wordpress" in a legacy cpanel
of a cheap shared web host (though in that case the web host should be setting
up certs automatically for them), but what exactly is complicated about
setting up certs for a dev?
[https://certbot.eff.org/](https://certbot.eff.org/) holds your hand through
the entire ~30 second process. It's simpler than most other tasks a dev needs
to do while setting up a website.

~~~
foepys
Sometimes it comes down to whether user-generated content with externally
linked resources is allowed on the site. E.g. forums often allows embedding
images by users and because users don't care about HTTP or HTTPS and only copy
the image link from somewhere, you will end up with "mixed content" warnings
and broken "locks" in the browser address bar all over the place.

The current alternative is to simply use HTTP, which doesn't yield any
warnings. When Chrome will mark all non-HTTPS sites as insecure this will
change, hopefully.

~~~
lucideer
This is a very good point, but as you say and the article states, the lack of
warnings for this is changing.

There's also the obvious question of having user login/signup on a non-HTTPS
site in the first place (pseudo-anonymous user accounts or otherwise).

------
jlengrand
That's weird. If I browse some of the sites in the list, I do see them
secure....

Example : [http://www.leboncoin.fr/](http://www.leboncoin.fr/) redirects to
[https://www.leboncoin.fr/](https://www.leboncoin.fr/)

~~~
Scott_Helme_
Our accuracy rate is currently around 99.6% so we're doing pretty well but of
course I don't think it can ever be 100% either.

The biggest thing we've come across so far is geo-sensitive handling of
requests. Some sites will redirect you to HTTPS or not based on where you are
making the request from! This of course means you might see HTTPS and we see
HTTP.

I think it's still fair to include those sites in this case because they
aren't serving all traffic securely.

~~~
jlengrand
Hey, thanks for the extra insight, I do appreciate. Interesting to know that
those sites show these behaviours too. Why could geo-location based redirect
be interesting?

~~~
Scott_Helme_
My guess would be that maybe sites have different infrastructure in different
regions and maybe they aren't completely aligned on their progress. I really
don't know why you'd intentionally have it like that.

~~~
jlengrand
I thought about country restrictions as well. I noticed most of the offending
websites were in China. Wondering is having SSL there is not allowed or
something.

------
Kartificial
Judging by the contents of the list for the Netherlands, we are doing quite
well: [https://whynohttps.com/country/nl](https://whynohttps.com/country/nl)

Most pressing ones are uva.nl (major University) and at5.nl (local but
relatively large news site).

~~~
sdoering
In Germany I thought if kind of sad, that a major automotive forum isn't https
secured (motortalk.de). I was asking myself, how they manage their user's
logins.

Then I checked. The are secured. Not sure since when, but maybe the data from
whynohttps isn't as fresh as one might think.

And lot of bigger press sites (spiegel.de, faz.net. computerbild.de) aren't
secured still. Kind of a shame imho.

~~~
mstolpm
The main reason for big media sites and forums not being https secured is the
interest of the advertising community. There was a huge community discussion
on sites like golem.de and Heise.de, which only recently switched to https.
Login pages are protected almost all the time.

~~~
sebazzz
That still keeps the session and login cookie vulnerable right?

------
creeble
I can recommend another site a just used yesterday for finding all the broken
([http://](http://)) image references is
[https://www.whynopadlock.com](https://www.whynopadlock.com)

The site I was debugging was a WordPress site that had somehow gotten the
images in its opening carousel set to [http://](http://) despite the fact that
the "header" module had a default of [https://](https://). Very useful to just
feed it the URL and notice these were the broken images; I could have grep'd
through a "show source" page, but whynopadlock.com made it easy for me to
identify that it was the header module of a site for which I had little
familiarity.

------
hkai
Nice to know that a bank, Sberbank, doesn't bother to use HTTPS.

------
robinduckett
BBC.com does have HTTPS, they support http for older clients I assume. They
still had a WAP site as far as I recall.

~~~
b2ccb2
The https request gets redirected to http:

    
    
      curl -IL https://www.bbc.com
      HTTP/2 302
      content-type: text/html
      date: Tue, 24 Jul 2018 08:55:34 GMT
      location: http://www.bbc.com/
      content-length: 0
    
      HTTP/1.1 200 OK
      Server: Apache
      Content-Type: text/html
      Expires: Tue, 24 Jul 2018 08:56:35 GMT
      Content-Language: en
      …

~~~
johneth
bbc.com redirects to bbc.co.uk in the UK, which is served over HTTPS. They
just flipped that switch a couple of months ago, so I'd assume that it won't
be long before bbc.com is also HTTPS.

------
popotamonga
I know nothing of https.

I put my sites on free cloudflare and i get https without having to do
anything, is that enough or?

~~~
leni536
Note that the "Flexible SSL" and even the "Full SSL" options don't protect the
traffic between your server and Cloudflare. You you need to enable "Full SSL
(strict)" as your SSL setting for that.

~~~
Maakuth
However, he is getting quite a sizable portion of all the security benefits on
HTTPS even with the current setup. I think it's quite a bit better than
plaintext http all the way. Troy Hunt has written well about this:
[https://www.troyhunt.com/cloudflare-ssl-and-unhealthy-
securi...](https://www.troyhunt.com/cloudflare-ssl-and-unhealthy-security-
absolutism/)

~~~
r1ch
You get a few benefits (protection against local interception) but it comes
with a significant downside as it takes away the ability for an end user to
identify if the connection is actually secure. For example I wouldn't enter my
card details or other personal info on a HTTP site, but when CF is in front of
it, I have no way of knowing if that's strict HTTPS to the origin or if most
of the connection goes insecurely over the internet. The other problem is that
CF makes it very easy for less technical website owners to click a button, see
a green lock and assume everything is fine.

------
alainchabat
[https://whynohttps.com/country/tw](https://whynohttps.com/country/tw).
Taiwan, Province of China. Taiwan is a country. This would be the correct
wording: Republic of China.

China used its influence at the UN to have that included in ISO:
[https://en.wikipedia.org/wiki/ISO_3166-1#Naming_and_dispute](https://en.wikipedia.org/wiki/ISO_3166-1#Naming_and_dispute)

~~~
ekianjo
its not just the UN. Almost no country recognizes Taiwan as a sovereign state.
No embassies in Taiwan. That is really weird but that is the current
diplomatic situation.

~~~
philliphaydon
Simply not true. Most countries recognise Taiwan. But you cannot deal with
China if you say that out loud.

~~~
ekianjo
What is your source for your claim?

~~~
philliphaydon
[https://en.m.wikipedia.org/wiki/One-
China_policy](https://en.m.wikipedia.org/wiki/One-China_policy)

It’s called the one China policy. I.e strong arm governments to not recognise
Taiwan in order to do business with China.

------
taf2
What's the point of encrypting the sites in China anyway? I mean obviously
everything you do online in China is tracked and not only that but shared - so
is it maybe better in China to just not encrypt to safe on the additional
power consumption? Really good green policy in China :D

~~~
zokier
State actors are not the only threats

~~~
taf2
I means it’s more about local corruption in China right which is driven by
perverse economic pressures that come from an overbearing centerialized
government power.

------
MrXOR
Another (very) bad news:

only 17.7% of HTTPS sites support HTTP Strict Transport Security (HSTS) ==
82.3% of HTTPS sites are HTTP!!!

[https://www.ssllabs.com/ssl-pulse/](https://www.ssllabs.com/ssl-pulse/)

------
vqrs
baidu and google.cn are high up on the list of non-HTTPS sites.

google.cn is an interesting one though: It redirects HTTPS to http, but the
site consists of an image that redirects to google.com.hk which is https-only.

Who knows what you see in China when accessing google.cn...

------
oblio
He he, this is quite funny:
[https://whynohttps.com/country/ro](https://whynohttps.com/country/ro)

Sites 1, 2, 3 are for pirating movies and TV shows :))))

------
kuahyeow
[https://whynohttps.com/country/nz](https://whynohttps.com/country/nz)

Ouch number 5 in NZ is a Credit card payment gateway

~~~
toomanybeersies
In their defense, they don't offer payments through the site. Their actual
payment gateway (sec.paymentexpress.com) is secured with https [1].

I'd be more concerned with the ecommerce sites on the list, like Rebel Sport.
Kmart at least does seem to redirect to HTTPS.

[1] [http://paymentexpress.com/merchant-ecommerce-
pxpay.html](http://paymentexpress.com/merchant-ecommerce-pxpay.html)

~~~
sebazzz
Yes, but if you can midm the http connection you can appear the main site
however you like. Including some login format or other way to obtain sensitive
data.

------
kevrone
You can figure out your own certs or manage the cert request/verification
cycle via Let's Encrypt...or you can let someone else do it for you. I
recently joined a company that offers HTTPS out of the box for any domain you
own: [https://blog.backplane.io/how-to-get-
https-80e1b28b878c](https://blog.backplane.io/how-to-get-https-80e1b28b878c)

I'm biased, but I do think it's a pretty painless way to enable HTTPS for
sites both big and small. No uploading of certs, no modifications to your web
app are necessary, it just works.

------
sp332
t.co is an unusual one. It's a link shortener that produces an https link if
you give it an https link, or an http link if you give it an http link. At
least I think that's how it worked but I'm having a hard time testing it now.

------
Rjevski
A nice list of sites to avoid.

------
kanox
I expected more porn.

~~~
Scott_Helme_
I expected less to be honest. The adult entertainment industry has been on a
huge drive to encryption recently. It makes sense if you think about the
content they serve, I guess people want more privacy there!

------
cordite
Why is Puerto Rico marked as a country at the bottom?

------
rc_bhg
I mean on some sites I make, I just don't care if its encrypted. I hate that I
have to just because all you mofo's have forced me.

~~~
CiPHPerCoder
> I hate that I have to just because all you mofo's have forced me.

I can't empathize with this perspective.

"Encrypt every packet with strong cryptography" is the mission statement of
the information security community ever since Edward Snowden went public.

The "mofos" have "forced" you to protect your users from attacks like
QUANTUMINSERT.

The "mofos" have "forced" you to protect your users from abusive ISPs
injecting advertisements that track them into web pages that gain no revenue
from these ads.

The "mofos" have "forced" you to protect your users from being hit with
increased malvertising and watering hole attacks because ISPs generally cannot
secure their own systems.

I think the wins here far outweigh the temporary inconvenience of having to
install/use certbot.

~~~
dragontamer
Okay, I'll bite.

Why would strong-encryption be necessary for a video game guide web-page? Say,
one about Factorio?

Some game communities are toxic. IE: Minecraft guides I'd host with https due
to the threat of scumbags and hackers. But Factorio's community is incredibly
lax and laid-back. So I would consider HTTPS to be a waste of effort and
resources.

~~~
filleduchaos
You're asking the wrong question, like many others who are resistant to HTTPS
everywhere. HTTPS isn't for you, the site owner (although you gain the not
insignificant benefit of knowing your content and traffic is untampered with).
It's for the people that visit your site, so when you say HTTPS is a waste of
effort and resources what you're inadvartently saying is that you don't give a
fuck about your visitors - or at least, not enough of one to do the least you
can to protect them from people who want to track and/or tamper with their
browsing activity[1]. Especially since solutions like Let's Encrypt with
certbot are free and take a couple of commands to set up.

[1] Unencrypted, pretty much everything about your internet traffic is laid
bare for any middleman - your ISP, the person who controls the router you're
connected to, some script kiddie on the same network as you - to both read
_and write_. Injecting ads or cryptominers, tracking what pages you visit,
changing what a page says, even straight up serving a different page. Why let
your site/server be a (potential) vehicle for exploitation, disinformation and
privacy invasion?

~~~
dragontamer
If the user is so paranoid about this sort of stuff, then they can go get a
VPS and control a large chunk of the network for themselves.

For everyone else, its a game guide. The worst that can happen is that they
get the wrong information about how Trains work in Factorio. There wouldn't be
a need for me to track users or clicks or whatever in a hypothetical game
guide community website.

As I stated before: I know some game communities (ie: Minecraft or Eve Online)
can be toxic. But the Factorio community isn't like that. So I'd be
comfortable hosting a Factorio webpage under HTTP.

If I were hosting a Minecraft or Eve webpage however (warning: toxic community
ahead), then I'd host it under HTTPS due to the dastards who troll and harass
others in that community.

\----------

That's the more important part btw: understanding your audience. Some game
communities are toxic and full of harassers, trolls and so forth. But other
communities are lax, friendly, and can get away with lesser amounts of
security.

~~~
joepie91_
> If the user is so paranoid about this sort of stuff, then they can go get a
> VPS and control a large chunk of the network for themselves.

And the last mile is still going to be just as unencrypted, non-private, and
tamperable as before.

You literally _cannot_ get end-to-end encryption/privacy without the host
supporting TLS.

It's really not an optional thing to support for you as an operator, and
especially now that Let's Encrypt is a thing, there's really no excuse for not
doing it.

(Now that we're on the subject of toxicity anyway: I'd say that depriving your
users from the ability to secure their network traffic, just because you're
trying to die on a weird hill, is pretty toxic behaviour.)

~~~
dragontamer
If I had usernames / passwords, then I'd use TLS.

But some webpages are simple, static one-off projects that I put out on behalf
of a community. I don't believe in ads and would rather pay for all the
bandwidth that my users would use. Consider it a donation "for the love of the
game".

Very, very simple, nearly static webpages, close to "neocities" level of web
design. No users, no passwords, just information I'm publishing to help a game
community out.

Nothing to steal, nothing to phish, nothing. Pure text, maybe a few images and
videos to elaborate on specific points.

[http://factorioguide.nfshost.com](http://factorioguide.nfshost.com)

\----------

I understand that TLS is important for any website with interactivity for
privacy reasons. But the above webpage is completely static and non-
interactive. Its old-school Web 1.0 stuff. There's nothing to steal, phish, or
cheat here. Literally nothing.

I just don't see the point in HTTPS-ing this site.

~~~
joepie91_
> I understand that TLS is important for any website with interactivity for
> privacy reasons.

Then you understand wrong. It's important for _any_ website, interactive or
not, for privacy reasons. Reader privacy is a thing regardless of whether
something is interactive. I don't know where you're getting the idea from that
'static' sites are somehow special.

~~~
dragontamer
I understand the importance of privacy in CERTAIN settings. Even if they're
static.

For example, Eve Online would 100% be under HTTPS. Period. That online
community is incredibly secretive, incredibly untrustworthy, full of scammers
and requires every bit of security on EVERY webpage.

Factorio's community? Erm... no. Trolls just don't exist in that community.
Unlike Eve Online, there's no warring factions of spies trying to take over
each other's online turfs "outside of the game". Factorio is a lax community
without any trolls or hackers.

A lot of it is understanding the userbase and general security posture. If I
were a serious Eve Online player, I'd give 100% secure settings, as much as
possible, due to the shennanigans that community is known for pulling.

~~~
CiPHPerCoder
Protecting users from malicious ISPs (or the criminals that hack malicious
ISPs) is a huge win for anyone.

> Factorio's community? Erm... no. Trolls just don't exist in that community.

HTTPS isn't about protecting "secretive" shitty people. It's about protecting
everyone.

~~~
dragontamer
From my understanding, Eve Online gamers transcend the game itself and stalk
your habits to the "real world" settings. Infiltrating forums and such. So
yes, I'd expect Eve Online players (the serious ones at least) to be very
privacy sensitive.

But ultimately, I don't think that this vague concept of "privacy" when
applied to a game guide really matters. People normally don't shuffle books
and anonymize themselves as they put books back onto the library cart for
example.

And I'm old enough to remember physical library cards with the names of
everyone who checked out a book. I don't recall any privacy concerns about
that. But maybe I'm just old-skool or something.

\-------------

With regards to malicious ISPs MITMing their users: they kinda control your
DNS requests, so good luck with that. I'm not sure if there really is a way to
fully secure against an ISP-level attack against the users.

An ISP can always inject into the HTTP -> HTTPS redirection, and serve HTTP
right there and then. HSTS assumes that the user has visited a clean version
of your site before, if a new user comes in without ever seeing the HSTS, then
the ISP still "wins" and captures your users on a fake HTTP version of your
site.

So no, the level of attacks you've described, I don't believe HTTPS solves the
problem.

~~~
CiPHPerCoder
> With regards to malicious ISPs MITMing their users: they kinda control your
> DNS requests, so good luck with that.

HTTPS security doesn't depend on DNS.

[https://developer.mozilla.org/en-
US/docs/Web/HTTP/Headers/Ex...](https://developer.mozilla.org/en-
US/docs/Web/HTTP/Headers/Expect-CT)

Please keep in mind: I do app security for a living.

> An ISP can always inject into the HTTP -> HTTPS redirection, and serve HTTP
> right there and then.

...they said, in a thread about a popular browser marking HTTP insecure.

Do you really think HTTPS-by-default is out of the question in the future,
especially if adoption rates exceed 99%?

------
gok
tldr: China

------
TheBobinator
Google is the major player pushing everyone to encrypt with HTTPS with other
companies hopping on board. They argued a populist viewpoint with what Snowden
revelaled they need to protect the public, but the real reason they pushed
HTTPS so hard has more to do with protecting their business and getting more
metadata.

It's no secret ISP's are consolidating and being bought up by media
conglomerates who want to secure the distribution method for their product and
exclude competitors in a new market. Those companies view the internet like
they view cable TV; it exists to deploy entertainment and advertising to the
public and to convert people into products for companies. But they need a
mechanism to figure out what is engaging, e.g. Nielsen Ratings.

There's only one thing more accurate than the traditional web bug or
javascript running on a webpage, and that's actually MITMing the traffic and
extracting the data raw. If you own the ISP you can do this. You can also
inject ad's. Ad's and Rating websites is something Google has built their
business on.

I'm really sure they have a sour taste in their mouth left over from from
google fiber due to the politics of ILECs trying to protect their literal
state-granted monopoly. And in all seriousness, with POTS being retired, the
government is granting monopolies over last-mile wire to cable co's.

So Google decided on the nuclear option: they've decided we're just going to
get everyone to encrypt their traffic and not just with easily SSLStrip able
stuff. We're going to push the standards organizations to deploy SSL\TLS in a
way nobody can crack it, then we're going to provide resources like Lets
Encrypt to make getting keys cheap, and then we're going to be beligerant
whenever the government complains about not being able to get at the traffic.

Now all the ISP's can see are HTTPS connections to AWS, Azure and Google on
their equipment; using IP's to try to figure out what site is what doesn't
work. They can still attempt to MITM the traffic and replace keys and
impersonate key repo's and I'm sure in a lot of cases they do, however, that
opens them up to class action lawsuits and criminal hacking charges. You don't
want a citizen organization charging your network architect with violating the
wiretap act; Network Architects are hard enough to work with, give them a
reason to tell their employer they are not going to commit a crime, and
they'll end up fighting their employers tooth and nail. Both of which I'm sure
Google would be more than happy to fund to protect its business.

The other advantage you get out of HTTPS is the session re-use feature. When
someone re-connects to your webpage, instead of establishing a new connection,
they can re-use the session they had before; this reliably tags a device and
allows you to identify connections from a device even when IP's are changing,
and would be more accurate than a browser fingerprint. This is not a new
technology or mechanism; IPSEC IKE sessions can last years.

In all candor, we've got military-grade encryption protecting general internet
traffic at this point and everyone on this forum is going to argue about
privacy without understanding where the market is at or why. That speaks
volumes to the times we live in and how effective astroturfing and
misinformation campaigns are.

~~~
crunchatized
> using IP's to try to figure out what site is what doesn't work.

Every mainstream browser sends the server's domain name in plaintext at the
start of the TLS connection,[0] so (short of domain-fronting, which browsers
don't do) it's generally not a mystery what site clients are talking to, even
if they used DNS-over-TLS. ISPs still have that metadata.

TLS session resumption could theoretically be used for tracking users, but why
would Google benefit from doing that when it already uses HTTP cookies? The
actual benefit is one fewer round trip, making the web, and all of their
sites, faster to load.

It's far more plausible that they're pushing to secure the web with HTTPS and
Certificate Transparency because an insecure web ecosystem is just plain bad
for business, and makes us all more insecure. It doesn't require spite or a
zero-sum game of tearing down the competition to explain pushing HTTPS and
Certificate Transparency, which lack real nefarious downsides for users.

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

~~~
TheBobinator
First, thanks for the link. I didn't know they implimented SNI after TLS 1.0.
I had always thought TLS would initiate a connection to the server
infrastructure first, then establish another tunnel in a tunnel for sites that
are hosted off of the same IP. It seemed like a more sane explination to what
I saw in wireshark and firewall logs. That also explains why older firewall
firmware had issues with getting sites out of TLS connections but newer
firmware doesn't. Looks like I have more studying to do.

I'll agree with you that there are substantial ancillary benefits to added
browser security well beyond the scope of this discussion and to continuously
hardening any infrastructure in general. From a business perspective, those
are always worthwhile investments in of themselves simply from the standpoint
good security means you have a discplined, well-thought-out system in place.
But, you cannot discount the fact that Traditional Television is a direct
competitor to Google and the internet in general and that is not a primary
motivating factor in their decision to enforce encryption. Large companies
simply do not mess with their core products for the good of the public, doing
so shows the company is not loyal to employee or stockholder interests both of
which shouldn't be disregarded for a variety of reasons. I'll agree companies
can decide not to take things too far, but they won't disregard their own
interests either. Assuming as such is a naieve belief.

------
CiTyBear
Why no https ? I think we know why...

~~~
paublyrne
Why?

~~~
ewiewi
They probably meant that the reason is malicious, to spy on traffic.
Especially since a good chunk of the top sites on that list are Chinese which
is known to have generalised spying on internet users.

~~~
Rjevski
However, in a shitty regime like China, surely the government can ask the
websites to just hand over the private keys and disable prefect forward
secrecy, allowing government spying while preventing anyone else from doing
so.

~~~
Scott_Helme_
Which is insanely difficult to do at scale and would take a considerable
amount of time and resources. Not to mention being really obvious! I'm happy
with making things crazy hard for the bad actors out there.

------
dvfjsdhgfv
There is a good dissection of these popular arguments in favor of HTTPS on
static websites that don't have any forms:

[http://webcache.googleusercontent.com/search?q=cache:Ka_e9-V...](http://webcache.googleusercontent.com/search?q=cache:Ka_e9-V0fB8J:n-gate.com/software/2017/07/12/0/)

In short: I have yet to see a really convincing argument in favor of HTTPS in
these scenarios.

~~~
Scott_Helme_
Have a look at this post: [https://www.troyhunt.com/heres-why-your-static-
website-needs...](https://www.troyhunt.com/heres-why-your-static-website-
needs-https/)

~~~
steventhedev
Please put yourself in the shoes of someone actually operating a site. Every
single issue mentioned in that post only affects end-users. Not a single issue
for the operator, who has many other issues that are more urgent such as
turning a profit, securing that database that got wiped last week, and writing
actual content. Point being that the incentive to force https for a static
site for an individual site operator is just not that great.

The sad reality is that http->https redirects are like vaccination. In some
specific cases they are needed (such as login pages), but for some it's more
about herd-immunity (normalizing https usage and ensuring availability). Mind
you that there's a solid argument for allowing self-signed certs to allow
encrypted but unauthenticated transfer. This mode allows MitM, yet does
protect against the threat model of a passive eavesdropper.

~~~
Scott_Helme_
"Please put yourself in the shoes of someone actually operating a site." \- I
run 8 sites right now and one of them is processing 10,000,000,000+ requests a
month. I speak from a position of experience on this topic.

"Every single issue mentioned in that post only affects end-users. Not a
single issue for the operator" \- so don't care about the user and the risks
we expose them to, only ourselves? This isn't really an approach I'm happy
taking.

~~~
steventhedev
With 10B monthly requests, you speak from a position of having an operations
team who spend 40+ hours a week on keeping your site secure (possibly even a
dedicated security team?). Most sites do not have that luxury. If you're doing
that on your own, then you're far from the average site operator that I'm
referring to here. In fact, most everyone on HN is not the average site
operator I'm talking about here.

My poorly communicated point is that by using extreme language like "I'm going
to hack your static site" dilutes the message and makes average operators less
receptive to more advice in the future. Troy does a lot of good work on
reducing friction and advocacy, but sometimes he puts out more extreme content
like this which makes me worry that it may have the opposite effect.

PS - Do you think the vaccine analogy works? I'd appreciate some advice on how
to improve it

------
mabynogy
I'm opposed to HTTPS everywhere because it comes with a lot of code (like
openssl) and a complicated paradigm (pki). We can do better and simpler at the
same time.

~~~
vqrs
> We can do better and simpler at the same time.

How?

~~~
mabynogy
I'm not into crypto but I found that method:
[https://en.wikipedia.org/wiki/One-
time_pad](https://en.wikipedia.org/wiki/One-time_pad)

~~~
lifthrasiir
One-time pad requires a pre-shared key of the enomorous length to be effective
in the World Wide Web. An impossible plan can be vacuously better and simpler
at the same time, guaranteed.

~~~
mabynogy
Only the length of the message.

~~~
ectospheno
The issue with one time pads isn't their security. That's fine.

The issue is key management. Both parties need the same key and it has to be
at least as large as the data you want to send. Each set of parties needs a
different key.

If you had a method to securely transmit such keys then you could just
transmit your data over it instead.

This is why one time pads are only used by countries to communicate with staff
overseas. You can send the pads by diplomatic courier for use in communication
later. There is no equivalent mechanism for your web activity and every site
on earth.

~~~
mabynogy
Yes there are. The two parties need to agree on a common source. It can be a
file somewhere on the web (an image) or a something that doesn't exist yet.

That's what happens with passwords.

~~~
Sohcahtoa82
How are the two parties supposed to agree when they've never talked to each
other before?

If I connect to
[https://www.SomeWebsiteIveNeverVisited.com/](https://www.SomeWebsiteIveNeverVisited.com/),
how is the web server supposed to tell me where to get the key? Or if I, the
client, am choosing where to get the key, how do I securely tell the server
where to get it?

Passwords work because they're being sent over TLS which we've decided is
"good enough".

~~~
mabynogy
Those problems exist with current systems. There is a phase where the two
parties must recognize themselves and agree they are legit.

