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.
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.
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.
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...
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.
Not to say this is a bad thing, but I'm sure Wordpress just broke a lot of links on their user's sites. For example, any embedded images from other servers not using HTTPS means that they won't load anymore due to browser policies, essentially breaking the links. It also means that any embedded images/videos/etc. will only work if the remote server has HTTPS. Again, not a bad thing, but it's pretty painful to have to deal with this with a lot of users that aren't experts on HTTP, and I'm sure it's a similar story at Wordpress.
I can flip the switch for default HTTPS on Neocities in a day. The hard part is figuring out how to not break user's sites in that process. Ideas welcome.
We've been working on this for quite a while and several parts of the solution deal with rewriting embedded URLs using HTTP. If you have any examples of breakage, let us know.
I'm not sure if WordPress is actually doing this, but they might be using something like camo[1] to transparently rewrite any http:// URLs to an image proxy running on SSL.
This gets harder to implement correctly depending on what kind of content you allow on your sites (i.e. does your CMS only permit sanitized HTML, or are users allowed to do basically anything?), so it's not a perfect solution for everyone, but it might work here.
Depending a bit on which browser we are talking about, passive mixed content (such as images) will typically be allowed through on default settings, while only active mixed content is blocked.
Not relevant to the WordPress part, but can someone explain to me why websites like eBay don't run on HTTPS except during login? Doesn't that allow any sniffer to steal your authentication cookies?
Yes and it doesn't even protect the password appreciably either.
User logs in with HTTPS, gets redirected to HTTP site and the MitM throws up the "Incorrect password try again" page. User types their password and transmits it over HTTP or JS steals it etc. etc.
eBay does it because they aren't sufficiently interested in protecting against MitMs.
The web isn't ready for HTTPS only yet but it will happen over time.
No.
Providing the cookies are set with secure flag (https://www.owasp.org/index.php/SecureFlag), that will mean the browser won't send the cookie over http requests, only on https requests, and to answer the other comment below about 'JS snarfing', that is mitigated by setting the cookie as httpOnly (https://www.owasp.org/index.php/HTTPOnly) which doesn't mean http vs https, it means not accessible via DOM JavaScript.
Do you know how they're stored on my PC? Last time I checked they were all in a giant C source file, which sounds like a pretty bad idea to me since I can't imagine it'll scale well.
The same humans who incorrectly add "www." when not told to are also unlikely to add "https://". So have the www. version redirect to the correct URL with HTTPS.
For that matter, since certificates with Let's Encrypt support arbitrarily many SubjectAltName (SAN) values, you can include the www variant in the certificate, so that your redirect can use HTTPS and HSTS.
This happens with the https:// vary rarely. The http:// case happens more often. This is one of the complications in adding HSTS headers with includeSubDomains. Right now, the http:// version works as expected, but if we added HSTS with includeSubDomains for "wordpress.com" those URLs would stop working and generate a SSL error.
Somewhat related - if you have a mapped/custom domain on WordPress.com, even though we are strongly no-www[0] the "www" will work over HTTPS, assuming that DNS for the sub domain points to our servers[1]
I never understood why you can't get a wildcard cert for * . * .example.com. Then again, the whole concept of wildcart certs being priced differently is pure price segmentation, so that's to be expected.
can you get a second certificate? i'm not sure how the technology works, but since let's encrypt is free i think it could also be automated to solve this problem
This is great news. All the more so as there is a tremendous amount of high-quality content under the Wordpress.com domain, something I chanced on while seeking out signs of intelligent life on the Internet.
I think this is awesome news. Hopefully we will see Chrome starting marking http only sites as non-secure and Apples App Transport Security (ATS) forcing people to switch to https all over the web within a year or two.
This is about custom domains, not subdomains of wordpress.com (they're using a wildcard cert for that, and have been for years).
Rate limits aren't much of an issue in that scenario unless someone has more than 20 separate subdomains set up as a WordPress.com blog under the same domain. Even then, you could theoretically get 20 * 100 subdomains covered every week if you're smart about which domains you combine on a single SAN certificate.
Let's encrypt is great, but I'm still running into people that have Chrome on WinXP or even IE8. It's crazy, I know. They did promise to start supporting both o XP because it had something to do with an intermediate cert somewhere. They didn't deliver on that promise. I don't blame them.
By the way, the cert on Wordpress.com is issued by GoDaddy, all the examples I could come up with are also. Guess it's a roll out process.
Let's Encrypt is great, but Start SSL has also shaped up considerably. A while back their process and the GUI was a real stumbling point. Today however it is a breeze to get it going. (Disclaimer: I am in no way affiliated with Start SSL)
While this helps *.wordpress.com users or custom domains using the wordpress.com back end, it's going to cause a ruckus with self hosted ones.
Neither WordPress or LetsEncrypt has any way to modify global server setting on any shared hosting environment. Slapping in an SSL certificate doesn't make a site secure, properly configuring the services that use the cert is what makes it secure.
GoDaddy isn't going to let Company Xyz rebuild Apache or configure cyphers server-wide...
In the end, while this is a move in the right direction, I fear it will give false confidence to many web providers that don't have enterprise experience with security fundamentals.
This won't affect self hosted sites, only those on WordPress.com's platform. A lot of the code for that service isn't present in the self hosted script.
[+] [-] dankohn1|10 years ago|reply
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.
[+] [-] afarrell|10 years ago|reply
[+] [-] developer2|10 years ago|reply
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.
[+] [-] geostyx|10 years ago|reply
[+] [-] Bahamut|10 years ago|reply
[+] [-] niutech|10 years ago|reply
[+] [-] melvinmt|10 years ago|reply
[+] [-] sargas|10 years ago|reply
This.
[+] [-] kyledrake|10 years ago|reply
I can flip the switch for default HTTPS on Neocities in a day. The hard part is figuring out how to not break user's sites in that process. Ideas welcome.
[+] [-] skeltoac|10 years ago|reply
[+] [-] pfg|10 years ago|reply
This gets harder to implement correctly depending on what kind of content you allow on your sites (i.e. does your CMS only permit sanitized HTML, or are users allowed to do basically anything?), so it's not a perfect solution for everyone, but it might work here.
[1]: https://github.com/atmos/camo
[+] [-] pred_|10 years ago|reply
[+] [-] sargas|10 years ago|reply
Growing pains. I think that will at least make people on the web more aware of the HTTPS "revolution".
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] pfg|10 years ago|reply
https://en.blog.wordpress.com/2016/04/08/https-everywhere-en...
[+] [-] wfunction|10 years ago|reply
[+] [-] ultramancool|10 years ago|reply
As for their reasoning... maybe performance, but more likely laziness.
[+] [-] jacobparker|10 years ago|reply
User logs in with HTTPS, gets redirected to HTTP site and the MitM throws up the "Incorrect password try again" page. User types their password and transmits it over HTTP or JS steals it etc. etc.
eBay does it because they aren't sufficiently interested in protecting against MitMs.
The web isn't ready for HTTPS only yet but it will happen over time.
[+] [-] iou|10 years ago|reply
[+] [-] pred_|10 years ago|reply
https://twitter.com/lgarron/status/718242465782853633
[+] [-] Matt3o12_|10 years ago|reply
[+] [-] geostyx|10 years ago|reply
[+] [-] simonw|10 years ago|reply
https://bestcrabrestaurantsinportland.wordpress.com/ works fine
https://www.bestcrabrestaurantsinportland.wordpress.com/ displays a certificate warning
Unfortunately I don't think there's a good solution for this. Humans are gonna www- things.
[+] [-] JoshTriplett|10 years ago|reply
The same humans who incorrectly add "www." when not told to are also unlikely to add "https://". So have the www. version redirect to the correct URL with HTTPS.
For that matter, since certificates with Let's Encrypt support arbitrarily many SubjectAltName (SAN) values, you can include the www variant in the certificate, so that your redirect can use HTTPS and HSTS.
[+] [-] barsxl|10 years ago|reply
Somewhat related - if you have a mapped/custom domain on WordPress.com, even though we are strongly no-www[0] the "www" will work over HTTPS, assuming that DNS for the sub domain points to our servers[1]
0. http://no-www.org/ 1. https://www.1912.me/
[+] [-] icebraining|10 years ago|reply
[+] [-] hayksaakian|10 years ago|reply
[+] [-] pg_is_a_butt|10 years ago|reply
[deleted]
[+] [-] dredmorbius|10 years ago|reply
https://www.reddit.com/r/dredmorbius/comments/3hp41w/trackin...
[+] [-] rogerbinns|10 years ago|reply
https://news.ycombinator.com/item?id=11457567
[+] [-] hising|10 years ago|reply
https://www.chromium.org/Home/chromium-security/marking-http... https://developer.apple.com/library/ios/releasenotes/General...
[+] [-] iimpact|10 years ago|reply
https://www.eff.org/HTTPS-everywhere
[+] [-] pred_|10 years ago|reply
https://www.eff.org/https-everywhere/atlas/
https://github.com/EFForg/https-everywhere/tree/master/src/c...
[+] [-] micro-ram|10 years ago|reply
https://chrome.google.com/webstore/detail/kb-ssl-enforcer/fl...
[+] [-] anarcat|10 years ago|reply
[+] [-] pfg|10 years ago|reply
Rate limits aren't much of an issue in that scenario unless someone has more than 20 separate subdomains set up as a WordPress.com blog under the same domain. Even then, you could theoretically get 20 * 100 subdomains covered every week if you're smart about which domains you combine on a single SAN certificate.
[+] [-] dogweather|10 years ago|reply
https://nonstop.qa/projects/387-hacker-news
(Free because I'm applying the GitHub model: free public projects, will eventually charge for private ones.)
[+] [-] teekert|10 years ago|reply
By the way, the cert on Wordpress.com is issued by GoDaddy, all the examples I could come up with are also. Guess it's a roll out process.
[+] [-] ikeboy|10 years ago|reply
[+] [-] brainpool|10 years ago|reply
[+] [-] RawInfoSec|10 years ago|reply
Neither WordPress or LetsEncrypt has any way to modify global server setting on any shared hosting environment. Slapping in an SSL certificate doesn't make a site secure, properly configuring the services that use the cert is what makes it secure.
GoDaddy isn't going to let Company Xyz rebuild Apache or configure cyphers server-wide...
In the end, while this is a move in the right direction, I fear it will give false confidence to many web providers that don't have enterprise experience with security fundamentals.
[+] [-] CM30|10 years ago|reply
So it won't break servers or shared hosts.
[+] [-] barsxl|10 years ago|reply
[+] [-] vram22|10 years ago|reply
[+] [-] ne01|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]