Why No HTTPS?

https://whynohttps.com

by iafrikan • 8 years ago

152 257 8 years ago

whynohttps.com

robinduckett• 8 years ago

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• 8 years ago

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• 8 years ago

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.

h2onock• 8 years ago

Wow, that's unbelievable!

toomanybeersies2• 8 years ago

bbc.com is http only for me. It redirects me to http if I try https.

jayflux• 8 years ago

There is work undergoing to migrate bbc.com to HTTPS.

Most BBC sites in the UK have already been switched over the past few months. https://www.bbc.co.uk/news was finished about a month ago. The BBC is a complicated beast and these sort of things take longer than you would think.

We redirect to http in the meantime to not have both being indexed.

jlengrand3• 8 years ago

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

Example : http://www.leboncoin.fr/ redirects to https://www.leboncoin.fr/

iliaznk• 8 years ago

So do I, I guess an automatic redirection to https from http is expected.

Aissen• 8 years ago

The real title should be "Why no HTTPS redirect", but it would be longer. Everything is explained clearly on the website.

minigab• 8 years ago

It doesn't work every time for me. If i open it in a new private session (chrome or firefox) there is no redirection... Probably a faulty configuration on their side.

Scott_Helme_11• 8 years ago

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.

jlengrand3• 8 years ago

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?

ape4• 8 years ago

I noticed in Canada several banks were listed. But they go to SSL.

Kartificial• 8 years ago

Judging by the contents of the list for the Netherlands, we are doing quite well: https://whynohttps.com/country/nl

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

sdoering• 8 years ago

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• 8 years ago

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.

CiTyBear• 8 years ago

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

paublyrne• 8 years ago

Why?

ewiewi• 8 years ago

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.

sonnyblarney2• 8 years ago

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.

lucideer3• 8 years ago

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/ 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.

pbhjpbhj2• 8 years ago

I use a cheap shared web host. My current and previous host both have LetsEncrypt implementations that take a couple of clicks. The former one was just default cpanel I think.

It is difficult if you want to understand the process, though no more so than, say, using Git IMO.

In short cpanel and other shared host panels make it as easy as the clicky-clicky Wordpress install

foepys• 8 years ago

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.

sethammons• 8 years ago

certbot has failed continually on my DO instance. It cannot update my cert on cron. I have to manually update my cert when I remember to do so. In fact, I had forgotten to do this for the last several months, so my site gets to display a nice scary warning for anyone who might venture forth and try https. I've searched how to fix it and nothing comes up. The site is static html and I've considered just removing https.

swebs• 8 years ago

but what exactly is complicated about setting up certs for a dev?

Seeing as how he mentioned AWS, it's a bit more complicated if you have a cluster of servers that are automatically managed. You have to set up a reverse proxy and integrate that into your cloud provider's workflow.

contras1970• 8 years ago

what exactly is complicated about setting up certs for a dev?

it may not be complicated but you cannot beat doing nothing.

kalleboo• 8 years ago

With certbot, it really is trivial for anything that's not using some very unusual setup. Shared hosting systems like CPanel have also added support.

Our biggest problem with the transition was mixed content issues with hardcoded HTTP URLs hidden away on long-forgotten pages.

zokier4• 8 years ago

On AWS can't you just use ACM which is supposed to be pretty painless

https://aws.amazon.com/blogs/aws/new-aws-certificate-manager...

Doesn't seem that bad

sonnyblarney2• 8 years ago

ACM combined with the various other services you need, especially Route53 or whatever, plus their byzantine new networking and security rules ... means you need to read a few sections of several different manuals to just do basic things.

AWS has become very complex over the last few years - there was a period where you didn't need admins. Now it seems you do again, just cloud admins, not local machine admins.

Sir_Cmpwn4• 8 years ago

many devs, don't [...] have the wherewithal to deal with SSL.

Those devs need to be shamed and taught a lesson.

many train operators don't [...] have the wherewithal to read the safety manual
many police officers don't [...] have the wherewithal to attend gun safety classes
many senators don't [...] have the wherewithal to listen to their constituents

vqrs2• 8 years ago

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...

popotamonga• 8 years ago

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?

r1ch3• 8 years ago

Unfortunately not. If you aren't setting up HTTPS at your origin then the connection still goes unencrypted over the internet. Full (Strict) is the only secure SSL option at Cloudflare.

leni536• 8 years ago

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• 8 years ago

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...

kuahyeow• 8 years ago

https://whynohttps.com/country/nz

Ouch number 5 in NZ is a Credit card payment gateway

toomanybeersies2• 8 years ago

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

moviuro• 8 years ago

...which is completely stupid because they score A+ on SSLlabs [0]. They even have HSTS etc., they really just have to preload it + add a 301 redirect.

[0] https://www.ssllabs.com/ssltest/analyze.html?d=paymentexpres...

sebazzz3• 8 years ago

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.

hkai• 8 years ago

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

alainchabat• 8 years ago

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

ekianjo2• 8 years ago

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.

philliphaydon3• 8 years ago

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

slaymaker1907• 8 years ago

I think both Taiwan and China officially say Taiwan is a province. Where they disagree is over which government is the legitimate central government of China.

philliphaydon3• 8 years ago

No.

dwheeler3• 8 years ago

Officially, many countries and businesses agree that Taiwan isn't a country, while continuing in practice to do everything that only makes sense if Taiwan is in fact a country. This is an old game that fools no one. I wouldn't fuss about the name, we all know what's really going on, and the name game probably saves millions of lives. You might find this video clip interesting:

https://www.youtube.com/watch?v=4AivEQmfPpk&t=2m53s

air7• 8 years ago

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.

repsilat2• 8 years ago

If it gets the https version into your browser history it can prevent a MITM in the future, though. Not all bad.

stereo• 8 years ago

That's why HSTS preloading is what you want to achieve. We've recently added openstreetmap.org and it was a fun project to make sure that everything would properly reply over https.

Scott_Helme_11• 8 years ago

Indeed the HTTP -> HTTPS redirect is only the first step in solving the problem.

A 301 redirect will offer some lasting protection as it can be cached but it's not really that great. The goal here is to take the first step to get on HTTPS and then longer term the sites can consider HSTS and eventually preloading.

Scott_Helme_11• 8 years ago

It might also be useful to note I have a HSTS Cheat Sheet for more info: https://scotthelme.co.uk/hsts-cheat-sheet/

dwheeler3• 8 years ago

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/ - 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• 8 years ago

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

jolmg• 8 years ago

This is also why it's preferable to use TLS-only ports for SMTP (465) and IMAP (993) instead of using the STARTTLS protocol extensions. Mail clients aren't required to enforce STARTTLS and might fallback to plain text when an MITM blocks the extension.

oblio• 8 years ago

He he, this is quite funny: https://whynohttps.com/country/ro

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

repsilat2• 8 years ago

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 :-)

ribasushi• 8 years ago

neverssl.com ( not a suggestion, it does exist )

pascoej• 8 years ago

captive.apple.com

glenjamin• 8 years ago

http://neverssl.com/ is what you're looking for here.

sebazzz3• 8 years ago

I just use example.com

bogomipz• 8 years ago

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

octosphere2• 8 years ago

And http://info.cern.ch/hypertext/WWW/TheProject.html still retains it non-encryptedness

jpetrucc• 8 years ago

http://http.rip is what I use

merb• 8 years ago

doesn't most OS's now have a captive portal which always check a url if it is accessible, if not they open a sane looking portal?

saulrh• 8 years ago

I use example.org for that. I wouldn't be surprised if it has to stay available on http for hysterical raisins, such as everyone using it in their tests and outage detectors.

dvfjsdhgfv10• 8 years ago

hysterical raisins

Thanks for making me smile!

aorth• 8 years ago

http://detectportal.firefox.com

mike-cardwell• 8 years ago

http://1.2.3.4 or any other random IP generally works for me. It doesn't necessarily have to exist.

tinus_hn2• 8 years ago

Example.com is defined to not have ssl.

gpvos• 8 years ago

Defined by what or whom?

(I'm still sad that example.com responds to anything at all. It was originally defined as a completely unused, thus unresponsive, domain.)

crunchatized5• 8 years ago

? https://www.example.com/ It's had HTTPS since at least 2014. [0]

[0] https://crt.sh/?id=5857507

sgshsf• 8 years ago

http://http.rip/

octosphere2• 8 years ago

http://info.cern.ch

Scott_Helme_11• 8 years ago

This really highlights the problem that we need a proper technical solution for and not hacky traffic interception/redirects!

I also created http://httpforever.com/ for this purpose until such a time that the problem is solved properly.

supertrope5• 8 years ago

It's not a technical or even standards setting problem. IIRC there's already a RFC for DHCP announced login webpage. It's business and legal - layer 8 and 9 problems.

Operating system maintainers have added captive portal detection to improve user experience. Hotspot owners often sabotage captive portal detection by whitelisting Apple and Google's CPD URLs! AAPL & GOOG have to change these URLs periodically and 802.11 vendors add the new ones in a cat and mouse game. So the customer's phone and thus customer think they're connected but they end up hitting a CP. Why? Because the CPD browser will close immediately upon receiving unencumbered Internet access. While many just want the legal liability limiting I Agree button to be tapped, many others owners want customers to see their store promotion/ad flyer page for longer than a second, place a tracking cookie, and do other value adds.

The interests of Wi-Fi network operators and users are not aligned. Right now only equipment manufacturers directly profit off Wi-Fi service. Hotspot owners can only indirectly earn money through attracting more hotel guests, cafe customers, etc. Some now harvest customer MAC address and in-store walking behavior. Ideally hotspot owners could receive a revenue share for offloading traffic from LTE, which would give them an incentive to be more loyal to users and maintain quality of experience.

https://news.ycombinator.com/item?id=13369038

snek• 8 years ago

you also always have to disable your custom DNS settings, and sometimes that means disable your DNS over TLS or go without internet :(

mintplant• 8 years ago

Recent versions of Firefox should detect this and present a prompt to go to the portal login page.

torgoguys• 8 years ago

www.com is a short, easy to remember, parked domain I tend to use. It has some text ads, but is probably reasonably light on bandwidth.

neverssl.com, mentioned below, is one I seem to for some reason always struggle to remember it's name when I need it. I end up typing things like nossl.com or neverhttps.com and such...

nkristoffersen2• 8 years ago

example.com is great for testing http. And it’s owned by IANA and not some rando. No ads either and easy to remember.

wdroz2• 8 years ago

That's why I always use my DNS tunnel. You can bypass such system on almost all public wifi.

oliwarner5• 8 years ago

Almost all? You've had access to some pretty crappy captive portals.

In my experience most portals' firewalls block all traffic (at IP level) except ports 80 and 443, which are transparently redirected to their auth server. Tunnelling isn't an option because you just can't contact anything else.

And it's not like I'm describing something that's hard to do. You've been able to script this stuff in iptables forever.

dijit• 8 years ago

captive.apple.com

I love this site.

syncsynchalt• 8 years ago

hp.com is still not strict and is quick to type. No guarantee that they won't turn on HSTS tomorrow though.

mustak_im• 8 years ago

For a long time I used my bank's homepage to get me redirected to the login page. Until the (reluctantly) forced HTTPS. Since then I'm using http://neverssl.com :)

mabynogy17• 8 years ago

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.

vqrs2• 8 years ago

We can do better and simpler at the same time.

How?

mabynogy17• 8 years ago

I'm not into crypto but I found that method: https://en.wikipedia.org/wiki/One-time_pad

trothamel• 8 years ago

Perhaps something like content based addressing, or using something like certificate transparency to protect site contents.

The problem with https everywhere is - for all its good aspects - it adds a layer of fragility to the web. It seems like we're leaving the day where a website can simply be, untouched, for decades. Now if you don't update your TLS certificates every few months, the thing goes poof.

It would be nice if there was a good way to publish content to the web without having to tend it constantly.

Rjevski2• 8 years ago

A nice list of sites to avoid.

TheBobinator2• 8 years ago

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.

crunchatized5• 8 years ago

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

TheBobinator2• 8 years ago

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.

dvfjsdhgfv10• 8 years ago

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...

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

Scott_Helme_11• 8 years ago

Have a look at this post: https://www.troyhunt.com/heres-why-your-static-website-needs...

steventhedev2• 8 years ago

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.

dvfjsdhgfv10• 8 years ago

Let's sum the discussion up - the advantages of HTTPS on static websites is that the content can't be (1) sniffed, (2) manipulated. To which I reply that (1) the person able to sniff your network traffic is also able to see or quite reliably predict what URLs you visit, and (2) if someone is modifying your network traffic specifically, you have much bigger problem than the one that could be solved by HTTPS. And really, each time I hear "HTTPS is secure" I get frustrated, as if people really had no idea how these protocols work.

rurcliped• 8 years ago

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• 8 years ago

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?

xamuel2• 8 years ago

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)

zokier4• 8 years ago

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

Different sort of security. While I don't agree with OP, the logic here is somewhat sound: he is concerned about the threats against the server. It is reasonable to claim that TLS increases the attack surface, because any any vulns in TLS implementation would be purely additive to the potential vulns in the HTTP server.

UncleMeat7• 8 years ago

I can't understand this opinion. So what if it only negativity affects a few users? How do you feel about ML that produces problematic results for a portion of users? Security is correctness.

pixl973• 8 years ago

The vast majority of my customers don't experience MITM data modification while reading my content.

[citation needed]. You have no idea if that is the case or not. Too many ISPs inject ads, javascript, or other horrible technologies (flash) in to customers HTTP streams.

Users have no idea if what you are serving them is what they are receiving. If this is content like code samples they can be corrupted my malicious users. If it's political content the message can be altered.

<hyperbolic>I mean, we all know rurcliped is a Nazi, their website said so the other day. </hyperbolic>

GordonS• 8 years ago

An option is to write your own web server and have the likes of Cloudflare provide TLS (and a bunch of other stuff!) on top of it for free. Best of both worlds.

taf22• 8 years ago

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

zokier4• 8 years ago

State actors are not the only threats

taf22• 8 years ago

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.

supertrope5• 8 years ago

It's doing something. After Google deployed TLS and obviously did not obey government data requests the government blocked Google domains entirely. Kind of like how Russia blocked Wikipedia entirely because TLS does not allow fine grained per page blocking.

rc_bhg• 8 years ago

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.

mlfn• 8 years ago

Who's forcing you?

donatj• 8 years ago

Chrome, mostly.

diafygi• 8 years ago

And I hate the fact that I can't trust the network to not modify your sites when I visit them. So I guess we can both be mad together.

Remember that https offers both privacy and integrity, so even if you don't care about the privacy, you should care about the integrity.

whorleater• 8 years ago

you should care about the integrity

I mean, there's the option to not use my site. Can I take a stand against HTTPS because I believe PKI to be a dumpster fire?

CiPHPerCoder4• 8 years ago

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.

dragontamer13• 8 years ago

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.

strictnein2• 8 years ago

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

Installing certbot isn't something you can do on 100% of hosts. Switching hosts is also a pain.

jonafato2• 8 years ago

HTTPS is for the users' benefit. They should be able to trust that they're getting the content they asked for without modification or snooping.

kanox• 8 years ago

I expected more porn.

Scott_Helme_11• 8 years ago

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!

sp332• 8 years ago

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.

creeble• 8 years ago

I can recommend another site a just used yesterday for finding all the broken (http://) image references is 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:// despite the fact that the "header" module had a default of 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.

gok• 8 years ago

tldr: China

cordite• 8 years ago

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

kevrone• 8 years ago

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

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.

MrXOR• 8 years ago

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/

Why No HTTPS?

Related Stories