Hacker News new | ask | show | jobs
by dankohn1 3723 days ago
Kudos to the Let's Encrypt and Wordpress teams. This is what the future looks like. Every webpage needs to be encrypted, and http (as opposed to https) needs to go the way of telnet (as compared to ssh).

What's particularly great is that there is no configuration of any kind for Wordpress authors or their readers. Like they have done, we need to always default to secure.

7 comments

There should still exist one well-known unencrypted page. Sometimes, I need to log in to hotel or airport wifi and therefore need to accept a MitM attack. I would prefer this not to be the case.
Apple products use this one for hotspot detection:

http://captive.apple.com/hotspot-detect.html

I just have it bookmarked now. It's the one bookmark I use.

Hotel or airport wifi operates in that way because they can do so without inconvenience too many customers. If it becomes too cumbersome that they need to send in a technician every time a customer is not a sysadministrator who can figure out how to get the wifi to work, then market forces will make sure that they use something else.
I use http://xkcd.com, but that works.
What would one well-known unencrypted page do to mitigate that?
If you go to a http page, and haven't logged it, it will redirect you to the login page. If you try that over https, it just fails.
Oh, now I feel dumb, I thought this was a security comment and not a practical one. Thanks for clarifying.
The solution for all wifi clients is to do what iOS and Mac OS X has been doing for years, which is validate internet connectivity when connecting via wifi. If there's a captive portal standing in the way, it pops up a simple webkit view automatically. You don't even have to open a web browser.

It would be nice to have a more formal standard (e.g. supplying an authentication URL along with the DHCP response) but to be honest, this emerging de-facto standard is perfectly serviceable.

> you don't even have to open a web browser.

It would be nice if that worked consistently, but having just spent 2 weeks in airports and ho[s]tels in the UK & Ireland, it doesn't yet.

On the rare instances where it has failed me, I have diagnosed the problem to be the router allowing (or faking, not sure) a success response from http://captive.apple.com/hotspot-detect.html

If anyone has coded a captive portal to behave differently when it sees captive.apple.com they should be ashamed. All they're doing is making life difficult for everyone unnecessarily.

Google should do it on 8.8.8.8 just to make it more famous, but in general think about the meta websites defined in the W3C/IETF standards, such as: http://example.com
My go to is http://google.org.

Along with the 100 million in grants they write yearly, they provide a valuable social service for those more fortunate.

I use http://purple.com for this. It's easy to remember and always up.
The one thing a lot of people don't consider is that placing an entire site on https/ssl/tls ruins the traditional approach to caching. It used to be very simple to add a full-page caching layer in front of your unencrypted application. TLS completely destroys this. You can no longer simply plop a proxy cache in front of your application.

There are numerous approaches to make tls-for-all work, but they take more engineering effort. And some introduce security problems, like people who use CloudFlare which decrypts your traffic and then (optionally!!!) re-encrypts it between their servers and yours. Even taking the best encryption scheme with a CDN like CloudFlare still means that the CDN has full access to unencrypted payloads. That is an insane amount of trust to give away to a 3rd party company.

There is also an impact for large organizations that run everything through a local cache (like Squid). You can't share a cache between multiple clients when TLS is used. This push to encrypt everything means we're at the end of the era where such caches are useful. Does BuzzFeed really need to be encrypted?

One of the largest gaps in encryption in general is still performance. You hear all the time how TLS adds almost zero overhead anymore. This is simply false for most of us. Not everyone is Google who has their own custom low-level encryption implementation. Those of us using off-the-shelf software continue to pay the price of CPU overhead.

> It used to be very simple to add a full-page caching layer in front of your unencrypted application. TLS completely destroys this. You can no longer simply plop a proxy cache in front of your application.

I wouldn't say it's no longer possible. You have to do your caching before the TLS termination, and you'll have to pay the encryption overhead for every resource.

> This push to encrypt everything means we're at the end of the era where such caches are useful.

You can still do this kind of caching if you install your own CA certificate on all your devices. Almost all enterprise deployments will do this anyway so that their security appliances can scan TLS traffic. Squid supports this.

> Does BuzzFeed really need to be encrypted?

Yep! Otherwise, that free WiFi at your favourite cafe, or your ISP, might inject malicious code or ads.

> You hear all the time how TLS adds almost zero overhead anymore. This is simply false for most of us. Not everyone is Google who has their own custom low-level encryption implementation. Those of us using off-the-shelf software continue to pay the price of CPU overhead.

Obligatory reference to https://istlsfastyet.com/

There are two aspects here: Handshakes and encryption performance. Handshakes are expensive, you can probably do about 500-1k handshakes per core per second with a 2048 bit RSA key. This is usually no big deal in production because you can use session resumption, meaning once you've completed a handshake with a user, you can skip that part until the cache expires (people tend to use one day as their lifetime).

The second aspect, raw encryption performance with a symmetric cipher, is something you don't get to complain about unless you're Netflix. Any server CPU with AES-NI can push at least 500MB/s per core per second, probably more. You'll run into some other bottleneck way before TLS performance becomes an issue. Unless you're Netflix, of course[1].

[1]: https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf

    like Squid
I think the answer to that is that the days of local caches being useful are long gone. The top traffic count on many networks ends up being things like Youtube, and very few people are going to see the value in attempting to locally cache that sort of data.

Even if served over http, tonnes of traffic is uncachable anyway due the increased use of dynamic resourcing. Even this basic looking HN page will end up uncached by Squid because I'm logged in, regardless of https being in the picture.

As for performance, I've played around with benchmarks using Goad on a micro tier EC2 instance and never found an appreciable difference between http and https.

> That is an insane amount of trust to give away to a 3rd party company.

Why is it insane to give that trust to a carefully selected business partner, but not the random 3rd parties with access to plain HTTP content? Also, your CDN has access to unencrypted payloads anyway, whether it's encrypted elsewhere or not.

I still see login pages over http sometimes. I will be happy when I rarely see any http pages. I wonder what would happen if Chrome made all http pages red to indicate insecure...
There's a Chrome flag you can enable for that experience today, as it's only a matter of time before that is default. I use this and so this is how the TechCrunch article shows for me: http://i.imgur.com/c8Cz7S4.png
And, that imgur link is also a broken lock? ;)
That blog post is from January and Firefox Dev Edition 46 has since advanced to Beta. The insecure login warning will ship to the Firefox release channel on April 26. :)
Just the fact http was the default for all websites hosted on WordPress.com is really weird to me. All those websites had all the passwords sent over plaintext.
Note that this is about custom domains hosted on Wordpress.com's infrastructure. Blogs that were hosted as subdomains of wordpress.com have been using SSL since 2014 according to the original announcement. Let's Encrypt allowed them to enable it for custom domains without delivering a truckload of money to a CA.

The original announcement is a bit more precise on this.

Nope — login pages have been https for many years.
That's because Google rewards on page speed, and SSL used to make you lose the game. So if you want your wordpress to be well referenced, it used to be better to have it insecure.

Additionnaly if you published both on HTTP and HTTPS, you were flagged as duplicate content. Fortunately they've reordered the incentives now.

I'm speaking out of ignorance here, but why does every webpage need to be encrypted? What about simple static sites that are only serving information?
1. Comcast (the US ISP) inserts advertising in http webpages, to the point that it breaks webpages, delivers malicious content, or replaces a 404 with a "Do you want to download [that IE toolbar/Chrome extension which inserts ads in every page]". ISP are extremely bad-behaved. This is active spamming.

2. Hey Joe, I've seen you've consulted wikipedia pages about unionizing. What about we give you plenty of free time to unionize yourself?

2. Have you ever downloaded the pic of a sexualized person? Do you have his/her ID card on file? If not, does she "look like" <18 years old? I don't mean is she actually, but what would a jury of average blokes (who neither care about truth and want to have the trial over soon) vote for if they had to vote? Boom, you're jailed as a child pornographer, even though the model was professional and over 25. That's the beauty of blackmail. This could happen as soon as you have professional secrets, or you are annoying for a competitor or a colleague, so as soon as you do anything meaningful in this world.

Are there any other method to prevent / protect information being hijacked without going for encrypt?
Why not going for encryption? The reasons usually provided by detractors aren't satisfying: "Police needs to access consumer data because they need to investigate terrorism". This is false because the police doesn't even use the current investigation methods. For example:

France and Belgium were recently submitted to terrorists attacks. The police didn't have detectives for such terrorist cells in the first place, so full access to citizen's privacy wouldn't have helped if there was no investigation going on. You won't believe how simple is the root cause: Any organization is dedicated to justifying its growth, so police will constantly request for an upgrade of their gear, people and scope, such as computing methods to solve petty crime, while policemen have no incentive to risk their lives to investigate terrorism on the field. They, unfortunately, have no incentive in solving terrorism, because it will always be legitimate to say 'Oops, this terrorist cell wasn't detected, give us more means and people so we do better next time'. On the other hand, terrorists know very well how to protect their data, and it gives policemen huge pride and power to have access to citizen's private data - just check how many US policemen were condemned for stalking a girlfriend last year. So police access to private data is not going to solve terrorism, because there aren't enough forces dedicated to investigation anyway.

Another example: France has signed the Shengen agreement, which says it's better to join our police forces to protect the borders of Europe instead of each country protecting its own. Fast forward 30 years, we've let about 2 million illegal immigrants through, including ALL our terrorists who were born in France, went to Syria for military training and back. Talk about porosity! People with military training from an ennemy force are supposed to be arrested under Geneva conditions; They were well known and listed by our files, some of them were arrested by Turkey and given to Europe handcuffed and person-to-person, and freed later by European police for lack of means. So you see, there is not even a need for police to access to all SMS and phone calls. We weren't doing anything against terrorism in the first place. We've been lied to by politicians.

Also note that the US has become a police state and levied all their privacy protections since 2001. Did it solve terrorism? 2013: Boston attacks.

Terrorism isn't something police can reduce in the first place. Besides, going to foreign countries to destroy houses and spread poverty will only accelerate it, especially when using drones and non-judicial decisions. I'm flommoxed that France goes to Syria, because our terrorists were born in France. The only 3 things that eventually reduces candidates to terrorism:

- Investigations where police forces risk their lives. Not going to happen.

- For western-born terrorists: Good education, career prospects, loving wife and children. No racism. Not going to happen.

- For foreign countries: No Predator, no drones, no american/european attacks, no spies, no Israel expansion, just lest we parachute schools and books and food and toys for toddlers and education for women. Joint development. Remember the Marshall plan? We need to learn to forgive again. Not going to happen soon.

So don't expect terrorism to be over any soon. It's one of the risks of life, among with drugs, second-hand smoking and heart strokes.

On the other hand, the risk of not encrypting is to give people in power more information, and centralizing power even more, to the dismay of social mobility. For example, the #PanamaPapers couldn't have been investigated if police had access to journalists' communications, because they would have gently asked them to shut up.

Well nothing as drastic as what you mention. I was mainly thinking if there are any protection of hijacking website without the complexity of encrypting. Which as some have stated makes caching harder. And therefore lowers performance. I was hoping if there are solution without going to encryption.
So that you have assurance that you're connecting to the site you intended to, and not an imposter, and so you know that the information has not been altered in transit.
Not only that the high-level information on the page has not been altered, but also just simply that no code has been injected that could possibly lead to a drive-by download or other malware shenanigans.
Don't forget about loads of websites on cheap shared hosting, which cannot use Let's Encrypt or other free SSL certificates. And Telnet, used for logging in to a server, is much more dangerous than plain HTTP, used just for viewing HTML documents.
some cheap hosting providers started enabling SSL by default for all their users who use a subdomain (e.g. User.cheaphosting.tld) and mine just announced that they provide free SSL certificates for all custom domains by default thanks to letsencrypt.
Good to know! Can you share which one you are speaking of?
I thought of Lima city, but they are a German hoster (website is in German, data centers are in Frankfort, Germany). I'm sure you will be able to find many others. Lima city is free (as in beer) and have unlimited storage[1], unlimited bandwidth, support PHP and MySQL, and allow you to add custom domains (you can buy them directly though them for very reasonable prices).

Although they are free, they have very little outages but they area limited to PHP (a big no-go for all my projects these days).

Disclaimer: I'm in no way affiliated with them except hosting my homepage there. I've used them for quite a few years now and they allowed me to show off my PHP projects to friends when I was 14 or so.

[1]: they have a fair use policy and downloads (everything except, html, PHP, css, js, and image files) are blocked and need to be hosted on their download server, which has a rate limit. They will also monitor your account for abuse (so if you consume a lot of bandwidth because you hid your download in the JPG file, they will ban you).

Many cheap hosts are adding support for Let's Encrypt. This story is a prime example.
Of course techcrunch.com itself still does not support HTTPS.
They're an enterprise customer and not automatically enrolled into this for a few reasons. See https://news.ycombinator.com/item?id=11459229
> we need to always default to secure.

This.