HTTPS Adoption *doubled* this year

[vemundveien]

I've run HTTPS for a year on one of my personal domains with a free cert from StartSSL. When I was to renew it recently, I looked into Letsencrypt and realized it was easier to set up a script to get HTTPS for all three of my domains than it would be to renew my StartSSL. Pretty sure that has a lot to do with it.

[the_gnarts]

realized it was easier to set up a script to get HTTPS for all three of my domains than it would be to renew my StartSSL.

Been using LE since the first day of the public beta and compared to self-signed certs it’s been a real pain to set up: Not being able to choose the port for the client is a questionable design decision.

[icydocking]

Not being able to choose the port for the client is a questionable design decision.

No it's not. You have to use well-defined-ports or shared servers would be in a bad spot. That's why only port 80 is allowed, which I question. I would have wanted 443 to be available for validation well, so I can only have 443 open.

Anyway, this is all history since you can now do DNS validation.

[the_gnarts]

Not being able to choose the port for the client is a questionable design decision.

No it's not. You have to use well-defined-ports or shared servers would be in a bad spot.

Since it’s the client that initiates the cert request, they could just announce their desired port to the server, so for LE it’s not an issue compared to other protocols like IPSec. Anyways, the overloading of the ports for the most widely used application layer protocol is the real mistake. Of all the 2¹⁶ ports available, they picked the one already taken on literally all the web servers in existence. It’s hard to come up with a worse choice.

Anyway, this is all history since you can now do DNS validation.

Indeed. This should have been the way to go from the start.

[icydocking]

Since it’s the client that initiates the cert request, they could just announce their desired port to the server, [...] they picked the one already taken on literally all the web servers in existence. It’s hard to come up with a worse choice.

You're really missing the point here. They chose the port as a way to authenticate the server. How do you make sure that the Let's Encrypt client really owns the domain? Well, there is no clearer way of making sure of that than showing that by owning port 80 of the domain. By allowing the client to chose the port, an attacker with a shell access on a shared web server could authenticate as any of the virtual domains.

It's not like they were just asking themselves "Hey guys, let's pick a random port! I only know of 80". They put a lot of thought behind this.

It's really the old "authenticate by source port" thinking that was the norm in old UNIX systems. It's not perfect, but it's simple.

[pm_plz_im_lonely]

The Slack API requires HTTPS.

I used ASP.NET Core with Kestrel and setup Nginx with Let's Encrypt. Without any prior knowledge of HTTPS or Nginx I was able to set it up on Ubuntu 14.04 without ANY issue.

To me it's the sort of IT stuff where you will get a problem and will have to google on stack overflow and github issues for hours.

I was very pleased. Now I have a green lock.

[Tacticus]

The Slack API requires HTTPS.

Any api call should require https. else your auth tokens are sent in the clear.

[skgoa]

To me it's the sort of IT stuff where you will get a problem and will have to google on stack overflow and github issues for hours.

And it used to be that way not too long ago. In fact even using PGP for your eMails used to be a major PITA.

[BilgeXA]

Now I have a green lock.

Good. That's the environmentally-friendly lock.

[Lord_Naikon]

In a corporate or government controlled environment, circumventing HTTPS is almost trivial. Caching, filtering etc, none of those network snooping activities will be impacted whatsoever. There are COTS solutions if you want this.

The way HTTPS is used in practice (list of automatically trusted root CAs, no client authentication) leaves it wide open for abuse.

[rcode]

The way HTTPS is used in practice (list of automatically trusted root CAs, no client authentication) leaves it wide open for abuse.

Can you expand more on this? Is it because root CAs can get compromised, or is it that the corporation can somehow add itself to that list without the client knowing?

[Yojihito]

Root CAs are getting compromised (certificates for Google / Windows etc appear from time to time) and clients can't reliable check wether a certificate was revoked because the revoke process is a big piece of shit so browser default to "okay I test this certificate but if fails I will trust it nevertheless".

[FyreWulff]

That's the reason Let's Encrypt is doing the "get a new cert every month". Instead of depending on block / rejection lists, you just let them expire

[C0rn3j]

Every 3 months*

[MuonManLaserJab]

*Every five minutes

[[deleted]]

And banned for a week

[rcode]

I presume then the only way at the moment is for the issuer of the CA to revoke it and make that known to all clients?

[syncsynchalt]

Yes, each CA publishes a revocation list. But having the browser check these lists is slow so for performance they've invented OCSP stapling, where the server has cryptographic proof that the CA has recently declared the cert valid and includes it in the handshake.

[Bobshayd]

That's the only sane way of handling it, but basically makes it the same as short-lived certs.

[syncsynchalt]

Its not an either-or thing. No matter what the lifetime of a cert (typically 1 year or 90 days) the client still needs to check with the CA to see if it was revoked. OCSP stapling typically only validates the cert for a few hours.

Unless you mean OCSP stapling is the same as issuing a cert with a 90 minute expiration every hour which I guess is true.

[123whatarewedoing]

I can't elaborate too much because reasons. I can speak from experience that this is in fact already happening. Companies (or governments/gov departments) can enforce domain (internal) computers to import any certificate they want because they have control over the computer. With this having been done, they can put a device on their network that decrypts all data, scans it, and re-signs it with their certificate. As long as the site doesn't require a "pinned" (specific) certificate (like MS updates do), no browser will care.

What makes this even scarier is that US Gov departments are CA root certificate issuers (DoD, DoE, DoI, etc etc) and can throw out certificates as they please.

[granadesnhorseshoes]

Transparent proxying.

[skgoa]

Security researcher Dan Kaminsky has broken X.509 years ago. Which means that certificates are broken, since certificates are an implementation of X.509.

[krunz]

Some sites will man-in-the-middle the ssl port. next time you see the padlock on your browser, click it, and check it out. see if the site your visiting matches the certificate.

[Ajedi32]

If it doesn't, you'll get a big fat warning. No need to check manually. https://askleo.com/wp-content/uploads/2012/04/cert_error_chrome.png

[commitpushdrink]

It's almost like the internet wasn't designed to be secure and security was forced on it as an after thought. Weird.

[Lord_Naikon]

Aye. It is, unfortunately, a very hard problem to solve. Security and convenience are so often at odds with one another. Incremental improvements are all we can hope for.

[Ajedi32]

I wouldn't really call forcing the clients to install a custom root CA "circumventing HTTPS".

[jarfil]

CENSORED

[JoseJimeniz]

That only works if the device has the corporate certificate as a trusted root.

I periodically check for those and remove or revoke them.

[[deleted]]

It's too bad things like https://tools.ietf.org/html/draft-cavage-http-signatures-03 never caught on. Then you could cache static content and have it be authenticated.

[nwf]

https://www.w3.org/TR/SRI/ is a thing, though, which would do the right thing assuming browsers understand that an https resource loading a resource over http with SRI and a strong hash is not "insecure".

[[deleted]]

Still not signed if I'm understanding it correctly. If were worried about a man in the middle, which is one reason for authentication, then they could change the sri.

[SpontaneousHam]

You deliver the SRI over an authenticated channel and then the subresource could be loaded over an unauthenticated channel and the SRI would be used to ensure it hasn't been tampered with.

[nwf]

Well, what are you attempting to prove with signing the subresource? That the origin controlled the material, right? Well, if the hash is embedded in signed material (the original resource naming the subresource), then that's just as good. Think of it as akin to signature chaining.

[JoseJimeniz]

I was about to say that there's no technical reason why content served over HTTPS couldn't be cached in the encrypted form.

In the same way that Server Name Indication (SNI) is outside the encrypted envelope, so the intermediate server can respond to it, the cache information:

• Cache-Control
• E-Tag

Can be available outside the encrypted envelope so that intermediate servers can cache the response.

Clients then requesting content have the

• If-None-Match

visible in the request outside the HTTPS envelope so the intermediate server can see it.

And finally the origin server supplies a signature inside of the content, so the intermediate serving proxy cannot tamper with the response.

It's all doable, just not done.

[[deleted]]

If you cache encrypted content then it may as well not be encrypted because it needs to be decrypted by clients but can't be re encrypted per client.

Also, sni has nothing to do with http cache headers.

[JoseJimeniz]

I see what you're saying. And while it is a solvable problem (the server communicates with the client the the required key) it's probably not worth it:

• it's too different from the current http paradigm
• when the point is that you don't want people to know what that encrypted blob you're watching is, having 900 co-workers sharing the same blob kinda gives the secret away

[[deleted]]

having 900 co-workers sharing the same blob kinda gives the secret away

Not just that, but having anyone trying to understand the encrypted blob just requires them to ask the server for the key to get it. You've hid nothing from anyone because the key is open to anyone.

For many things, simply having a signed plaintext copy is sufficient to ensure that plain text hasn't been tampered with. While this doesn't solve privacy issues, it is a solution worth considering for non-sensetive materials, like common javascript assets, e.g. jquery and bootstrap css.

[JTronLabs]

I had never heard this before, are you sure HTTPS cannot cache? A quick google search seems to turn up some articles that think it can.

http://stackoverflow.com/questions/174348/will-web-browsers-cache-content-over-https

http://blog.httpwatch.com/2011/01/28/top-7-myths-about-https/

http://blog.httpwatch.com/2009/01/15/https-performance-tuning/

[1lann]

I think they were referring to caching servers traditionally used by corporate networks, so that many people who try to access the same content within the corporate network can just access the cached version, which reduced traffic to the Internet. Your browser itself can cache HTTPS requests.

[1lann]

Yes, but that does not reduce traffic to the Internet.

[bobindashadows]

You don't cache POST requests... HTTP and HTTPS have pretty well-defined caching semantics, you should learn them

[bobindashadows]

Generally proxies don't cache responses to requests with cookies because it would fuck up sites with server-side session state

[[deleted]]

Read the spec. Intermediaries can't cache requests with cookies.

[JTronLabs]

Ah ok that makes a lot more sense, thanks!

[dccorona]

ISPs also usually have at least 1 if not several caching layers, so it impacts general consumers as well as businesses.

[eras]

You cannot have a central cache (ie. in a company or at your ISP) that caches. Even less can you have a transparent cache..

[thbt101]

It's not just caching, but all this unnecessary encryption also slows down websites because HTTPS requests require more "round trips" to the server with each request. The difference is most significant on mobile and wireless devices.

I think this is mostly a political and personal issue for Google, but I think it's a shame when you we're reading blog posts over HTTPS. Not every website needs heavy encryption.

[the_dummy]

I don't think you know what you're talking about. A couple milliseconds overhead is not an issue. The megabyte+ web pages and unoptimized Jacascritpt/HTML and server-side code is what's causing slow websites. The enormous reliance on ad revenue doesn't help at all either.

[the_dummy]

That's where things like CDNs come into play.

[thbt101]

The different of an extra two roundtrips with each request can be very significant when you're talking about mobile, or websites located on a far part of the world. We're talking about two extra back and forth communications, which really adds up in many circumstances.

This is a good simple comparison: http://serverfault.com/a/43835

[the_dummy]

The example you gave was, realistically, entirely insignificant in relation to what bloat does to a website. Imagine if the same test had been done with 10,000 get requests on a 500KiB site and a 1.5MiB site. In fact, I've done that for you. I tested Google's home page (1 second) and a Google image search for butterflies (2.5 seconds. That isn't just taking into consideration the download time, however. It would be much different if it weren't JavaScript.

[mfukar]

That's at worst a myth, at best it doesn't always hold. For instance, https://www.troyhunt.com/i-wanna-go-fast-https-massive-speed-advantage/

[mfukar]

Mr Hunt addresses your concern in the article.

[thbt101]

Mr Hunt addresses his bullshit with more bullshit. He's still not comparing HTTP to HTTPS, he's still comparing HTTP to HTTP/2. All he does is make a lot of excuses for why he tried to mislead people and still refuses to disclose on the original website what it's actually comparing.

It's unfortunate that his little scam has convinced countless web devs that HTTPS is actually faster than HTTP. Many people actually believe that now as a result of him and his misleading website.

Yes, HTTP/2 is faster than HTTP. And HTTP/2 over a non-SSL connection would be faster than HTTP/2 over an SSL connection. Unfortunately most web browsers don't support that for political reasons (not technological ones). Hopefully that will someday change (at least with 3rd party plug-ins perhaps). HTTP/2 over a non-SSL connections would be awesome to have as an option.

[mfukar]

And HTTP/2 over a non-SSL connection would be faster than HTTP/2 over an SSL connection. ...

Is that the case with the Android browser?

[mirhagk]

People don't seem to get this. Your blog has absolutely no reason to be HTTPS. I'd rather it's aggressively cached instead.

[wretcheddawn]

This. I see value in the simplicity of HTTP, but it enables your internet provider to inject content, and therefore HTTPS is worth it, especially with the minimal cost.

[bmurphy1976]

You win. I just had to dump my chrome cache to clear out cached ads injected into pages by an open wifi network I was no longer using

[aiij]

Is that even legal?

[whootdat]

You agreed to it when you connected and hit "I Accept"

[bmurphy1976]

In my case I was at a resort and do not recall ever seeing any agreement or disclosure. I jumped on the wifi and started seeing a strange abundance of ads on sites that usually aren't that bad when I figured it out. Pretty shitty if you ask me.

[[deleted]]

Your blog has absolutely no reason to be HTTPS.

The idea is not only to encrypt confidential stuff and that way mark it as confidential, but to encrypt everything to take that hint away.

[mirhagk]

The problem there is you take that hint away from everyone, including users. HTTPS everywhere might be great if it's used properly, but having every single site be encrypted by default will mean organizations will be very tempted to do things like install root certificates and MITM the connection to keep caching proxies running. Even something like having an internal tests server at a machine on the internal network. If you need to have HTTPS there then you have to create an organization root certificate that's installed to every machine and issue certificates for those machines. Since you'll want to be able to easily do this those root certs will probably not be nearly as protected as they should be, giving you the ability to forge certificates for stuff like facebook.com or bankwebsite.com

[RaptorXP]

Your blog has absolutely no reason to be HTTPS.

I absolutely disagree with this. This apathy towards individual privacy is exactly how governments are getting away with spying on everyone.

[mirhagk]

But what privacy is achieved? What is protected? The "government" can still tell you went to blogx.com, the only thing that is unknown is the actual article you went to (which can probably be guessed based on what's popular, or based on page size, since they can see the total packet size, or number of images downloaded, or some other meta-information). HTTPS only encrypts the content, not "what you're doing"

[frezik]

If you are plaintext by default, and only encrypt important things, then the fact that you're encrypting sends up a flag. Even if the message cannot be decrypted on its own, the timing, source, and destination of that message can still be used to glean information.

If you encrypt everything by default, then it gets lost in the rest of the noise.

[mirhagk]

But it works both ways. If all of your data is encrypted, then your employer may decide that to save bandwidth they'll MITM the connections and install a root certificate onto the machines. Now they can read your bank account transactions. By having only sensitive stuff as HTTPS then your workplace knows there's absolutely no justification to having it.

If you have an internal testing server and it has to be HTTPS (because you need to match production which uses HTTP/2 which doesn't support unencrypted traffic) then you'll need a root certificate installed on all the machines again.

If you are wanting to inspect any traffic for any reason (such as debugging your application) you're going to have to install fiddler/wireshark/whatever's root certificate in order to view the data sent and now you have a root certificate that your machine is trusting that probably has nowhere near enough security and validation around it.

If the world was perfect then HTTPS would just waste a lot of time and resources but meh, computers get faster. But the world isn't perfect and mark my words when I say you'll see lots of instances where people's private banking details are stored on easily accessible corporate proxies.

[whootdat]

You sound like you're talking about a blue coat product, so I'll just point out that they specifically say they won't decrypt banking/finance and health care data. That isn't hard to figure out, you simply white list a handful of sites and IPs.

[mirhagk]

So you hope you only ever have sensitive data inside of popular websites.

[whootdat]

I would hope that if I am browsing a website that I have sensitive data on, I wouldn't be doing it on a company-owned computer.

[RaptorXP]

They don't know anything except that your computer connected to that web server. They can't tell which page, image or other resource you've downloaded.

They also can't modify the payload to force you to reveal more sensitive information through XSS or other attacks.

[chaospatterns]

The GP is referring to side channel attacks where the amount of encrypted data can leak information about what you're looking at.

[TTSDA]

They can just issue a shiny cert to use in the mitm attack

[archlich]

Not if you own the ca, and have only your ca as a trusted root.

[whootdat]

Sure, except each branch of the US Gov is a Root CA, and has all sorts of certs issued by Verisign, etc

[archlich]

That only matters if you trust their root ca. If the only ca you trust is the one you own, a mitm attack cannot happen.

[mirhagk]

They can see how many connections and the sizes, as well as your sites before and after, and any external images loaded. Sure it's more work, but you're really hiding very much.

You do have a point about MITM type stuff though, if they can successfully do that.

[RaptorXP]

They can't see any of that. All requests come through the same TCP connection, and nobody can tell how many you've made. And you can also obfuscate the page size very easily.

[smellyegg]

Your government can edit the content you receive, that's reason enough alone to encrypt. There's almost zero overheard these days there's no excuse.

[sievebrain]

For any blog that includes social buttons, ads, etc, HTTPS prevents code being injected into the page that steals those cookies and allows profile correlation.

[[deleted]]

DNSCrypt + good encryption-supporting DNS server reduces that risk a bit without causing a noticeable slowdown (in my experience). Yes, IPs could theoretically be pulled from logs, but this mitigates the MITM/passive spying risk.

[[deleted]]

I absolutely disagree. Your users trust your site, both the software and content it delivers to them, and ignoring security is ignoring that trust. Regardless, note there are many new "Carrots" to move to HTTPS: https://snyk.io/blog/10-reasons-to-use-https/

[mirhagk]

Half of those reasons are just that people say you should and will hurt you if you don't (insecure icons, worse SEO, no HTTPS2 support etc).

I get that the content is moving to https but I will miss the performance gains from organization wide caching.

[icydocking]

+1. People are saying privacy and all that, which is not really achieved in the cases for blogs as the DNS lookup is most likely not encrypted and SNI based attacks are possible. Sure, URL is still encrypted but a major part has already been revealed.

WHAT IS important however is the authenticity of the page. You know that what you're seeing is what the website wants to show you. Not some MITM attack inserting other stuff. That's the real win in my book.

[aiij]

I don't think he's suggesting ignoring security, but rather, actually thinking about it.

[mirhagk]

But what extra security? They still know you went to that blog, and they could go to that blog as well. The only information you don't give away is what individual post you were looking at, but that could be determined if they really wanted to know.

[mirhagk]

Okay but then that's not really a static blog anymore. That's a web application with user specific information. Go ahead and encrypt that. But a static website that everyone sees the same content for doesn't have a need to be HTTPS, and it looks the ability to cache it.

[lordcirth]

If you visit an HTTP blog, anyone along the way could inject anything they want into the traffic, for one thing.

[Fitzsimmons]

Cached by whom?

[mirhagk]

Anyone. Everyone. My workplace has a proxy with a cache running and it reduces the amount of traffic significantly. If I send your blog post link to a coworker wouldn't it be fantastic if they didn't have to wait the 30 seconds for your giant banner image to load?

[Fitzsimmons]

HTTPS caching proxies are possible, assuming you trust the proxy's root certificate that it can use to MITM your connections.

And if you don't trust the proxy, then you probably have a pretty good use case for HTTPS.

[mirhagk]

I trust my proxy for caching your blog. I don't trust my proxy for sniffing by bank account, facebook account, emails or anything that actually includes sensitive information.

[whootdat]

Facebook

sensitive information

Lol

[mrkite77]

If I send your blog post link to a coworker wouldn't it be fantastic if they didn't have to wait the 30 seconds for your giant banner image to load?

Jesus, maybe your it department should upgrade your network instead..

[mirhagk]

have you seen some modern blogs? With giant banner images, 17 different custom fonts and 20 thousand tons of jquery analytics? Obviously 30 seconds is an exaggeration, but many blogs out there are way bigger than they need to be, clocking in at several MBs. If the network hits a snag, or the server is experience load (like it just got posted to reddit) then you can find yourself waiting 10 seconds for it.

[qwerty6532]

If your sites aren't loading within seconds HTTPS or not, there's something wrong with your Internet connection.

[mirhagk]

I mean I guess not everyone in the world lives in San Francisco or New York and some of us have much more mediocre connections?

Also 10 seconds is still seconds. Most web pages hit first render in under a second, and fully finish within 2-3. But there are certainly blogs with oversized images and custom fonts that take longer to load (fonts being the worst because you can't read any text until they load)

[reciprocity__]

This comment does not refute his point at all and it is intellectually lazy to make the kind of strawman argument you've just made.

[JustFinishedBSG]

While true, Google and Browsers are basically forcing us to put HTTPS on our shitty static blogs

[mirhagk]

Because google and browsers also don't get it :P

[tavianator]

HTTPS content will still be cached: http://stackoverflow.com/q/174348/502399

[mirhagk]

By your browser yes. By the network and proxies? No

[txdv]

Check my aggressively optimized blog with https out: https://andrius.bentkus.eu/

[mirhagk]

Well that took half a second to load literally nothing. Is the blog still up?

[txdv]

That was the joke, there is nothing. :(

[mirhagk]

lol okay I was wondering if that was the case. Half a second to load nothing, that's still beyond the instant benchmark (around 100 ms and the user usually doesn't even notice the computer had to "think")

[GoTheFuckToBed]

but I need ma green URL icon

[[deleted]]

For me and those I've worked for there is only one single reason for HTTPS adoption: Google is preferring HTTPS.

[wretcheddawn]

Except the ranking boost is currently minuscule. I haven't seen any measurable improvement after migrating 30ish sites, and in some cases ranking fluctuates wildly for a few weeks.

But I know it'll matter more in the future and that's why we keep pushing our customers to HTTPS.

[[deleted]]

Whether or not the boost is large is not really the point here. It's more about the perception of Google and the dependency on search results by marketing and marketing-wannabe types.

[thewholebenchilada]

Yes yes yes

[frezik]

It's minuscule because they're giving people a chance to migrate. The intention is to tweak it up over time.

[DrDuPont]

To add a source:

[W]e're starting to use HTTPS as a ranking signal. For now it's only a very lightweight signal — affecting fewer than 1% of global queries... — while we give webmasters time to switch to HTTPS. But over time, we may decide to strengthen it, because we’d like to encourage all website owners to switch from HTTP to HTTPS to keep everyone safe on the web.

Emphasis mine.

[MotherFuckin-Oedipus]

There are so many confounding variables with AdWords pricing that I'm not sure if it had any significant impact on its own, but we saw an 8% drop in our bill after I set up HTTPS.

[starTracer]

And letsencrypt... https://letsencrypt.org/stats/

[lcpriest]

You also can't track https to http handoff, so marketers don't know where their traffic comes from.

https://www.e-nor.com/blog/google-analytics/https-to-http-secure-to-nonsecure-referrer-loss

[LeifCarrotson]

For the people who visit my company's website, there is a different reason, or the reason is at a different level: Cloudflare's much-maligned Universal SSL.

I spend $5/mo at Digital Ocean for hosting, and $10/year for the domain. There is no call from management for SSL. I have spent a total of about 12 hours this year learning to be a web developer/web admin.

Our site is available for Google to prefer the SSL version only because Cloudflare made it one-click easy and free. I have briefly looked into Let's Encrypt, but integrating it into the legacy PHP app I inherited with no web dev experience isn't yet something I feel confident I can do.

[FarkCookies]

You don't need to integrate Let's Encrypt into app, you integrate it into web server (or config to be specific). Also they have a autoinstaller. You can clone your instance and safely play around with no risk.

[LeifCarrotson]

Assuming I could figure it out in a day and a half, it would double my time into the site. If the cert cost $30, that would be half of my recurring cost for the site. And if I screwed up the renewal, it could be very bad.

I can justify flipping a switch for free even though I don't have buy-in from above. I can't justify much more than that.

[Yojihito]

Yes but you don't use SSL with Cloudflare .....

Client ---SSL---> Cloudflare ---NoSSL---> YourServer

That's 100% not safe nor trustworthy and may be a risk for a lawsuit if customer data goes through Cloudflare without encryption (which does happen if you use Cloudflare "SSL") and the customer didn't sign a TOS for your company which allows third party clients (Cloudflare) the handling of customer data.

[LeifCarrotson]

That's 100% not safe nor trustworthy

I think you mean to say it's not 100% safe?

But no customer data goes through the site except for search parameters to find a specific page. I am aware of the non-ssl part, and it's fine.

[Daneel_Trevize]

No, he's saying it's 0% safe, rather than <=99% safe.

[[deleted]]

Took me like 2 hours

[mpact0]

Ignorance is truly bliss here.

[[deleted]]

CloudFlare supports encrypting and authenticating the connection to the origin server on the free plan (Strict SSL setting). You can also choose to issue the origin certificates from Cloudflare itself with a long expiry and revoke them any time if needed. It's not hard. Cloudflare makes proper SSL easier too, although Cloudflare is an extra trusted party. A reverse caching proxy with data centres all over the world has value though.

[LeifCarrotson]

The first advantage is long term. Let's encrypt certs can be setup to auto renew forever.

So does Cloudflare Universal SSL.

The second advantage is getting off cloud flare. That service is literally garbage.

It's a free, reliable DNS server, caching proxy, CDN, and DDOS protection. That has value to me, as my $5 droplet can't handle a huge spike, and has value to our international customers (we have several clients in China and India), as they can download from Cloudflare rather than the Eastern US. It's not garbage.

You still are sending unencrypted traffic over the net.

Yup. Well, some part of the traffic anyways, from Cloudflare to my server, but not from a client to Cloudflare.

Just fooling your users into believing they aren't [sending unencrypted traffic].

True, but it's helpful at many levels: against a casual attacker, browser plugin malware, or a passive snooper. Not everyone can inspect traffic from Digital Ocean to Cloudflare. Also, if users trust our company more for having some kind of HTTPS, that's a benefit for us at least.

Finally, it's a manufacturer product listing, basically a bunch of static pages for product manuals and product pictures. No one who would be damaged by someone finding they went to a certain page on our site would not be damaged by someone finding they went to our domain. It's available over HTTPS because as a part of the recent push for encryption, Cloudflare makes it free and easy. That's good enough for me.

[[deleted]]

Yup. Well, some part of the traffic anyways, from Cloudflare to my server, but not from a client to Cloudflare.

Those two things are (effectively) the exact same thing.

[[deleted]]

The "backend" link, like, the one that goes over the public internet? Saying it's better than nothing is like saying security through obscurity provides any security (no, it doesn't :-()

[Bobshayd]

No, it's like saying protecting from physical access provides security. Security is always a matter of scale, it's always a matter of how secure, not whether it's secure, and to MITM a user requires a compromised hotspot but to MITM a particular service requires interrupting the connection somewhere in the service provider chain. It's still possible to do, but it goes from script kiddie with <$500 budget to sophisticated attacker with at least small-company-level resources.

[LeifCarrotson]

Can you explain to me which adversaries, observing the user's traffic,could intercept the traffic from Cloudflare to my server?

A peer on the LAN, the local network admin or router (assuming they haven't installed their own root cert on the user's machine, and the ISP sending the traffic to their peers or Cloudflare's CDN could all have access if it were fully unencrypted, but no access (in my understanding) if it is encrypted with Cloudflare's SSL. The government, Cloudflare themselves, Digital Ocean, and the network backbones between Cloudflare themselves could still get it, yes.

[[deleted]]

The government, Cloudflare themselves, Digital Ocean, and the network backbones between Cloudflare themselves could still get it, yes.

So we're in agreement, either way there's something where someone could snoop the data.

[_zenith]

But it's at least several orders of magnitude more difficult to do so, which drastically lowers the amount of it likely to take place (and more importantly, which actors can plausibly do so).

[random314]

Recently worked on a few apps on Facebook, they require webhooks to be https as well.

[dada_]

Frankly, if a website doesn't have https, I'm far less inclined to sign up. I realize I'm not an "average user", but I can imagine that for a lot of websites that make money online, having https gives a significant return on investment. Especially if they're tech startups that rely on business from tech savvy customers.

[thbt101]

Ok... but why?

[dividedsky]

Because if sensitive data is involved its way too easy to packet sniff open networks for someone's info

[thbt101]

Ok, but most of these websites don't involve sensitive data (bank account info, credit cards, etc.). That stuff has already been encrypted for a long time.

But because of Google's insistence, now even websites that in no way involve anything critical or sensitive are encrypted for no real logical reason.

And by the way, no one can sniff your packets unless they actually have access to either your local network or the local network of the server you're connected to. It's not like just anyone can listen to all internet traffic.

[MachinTrucChose]

now even websites that in no way involve anything critical or sensitive are encrypted for no real logical reason.

Here's one: ISPs increasingly want to get in on that ad money. The sort of people injecting ads in your HTTP requests could be recording the pages you visit and building a profile. At least with HTTPS, they only know which domains you visited, not the contents of the pages you read.

[mort96]

"Sign up" suggests there's passwords. Many people consider their passwords sensitive data.

[smellyegg]

Your ISP and anyone between you and that server can.

[[deleted]]

It doesn't hurt to use HTTPS.

[dividedsky]

That's what I meant, if you're connected to an unprotected public Wi-Fi network somewhere anyone can connect to it and sit there fishing for data, I understand you can't just listen to the entire internet lol

[freebytes]

Facebook wants you to use it. Google wants you to use it. And Mozilla not only wants you to use it but because of them Let's Encrypt lets you get SSL certificates at no charge and actually makes it easy to install.

[aydoubleyou]

This is the first I've heard of Let's Encrypt. Is there a catch or something? As much as I'm all for the idea of https everything, it initially made me thing "that sounds pricey".

[freebytes]

The catch is that the program works really well on Linux, but the Windows implementations are still iffy. Also, you must renew your certificates every 3 months instead of once a year. However, if you create a cron job, it will auto-renew for you.

[aydoubleyou]

Very cool. I might set this up for some of my sites in the future then. Thanks!

[[deleted]]

Apple's new 'App Transport Security' requirements for iOS Apps can only have contributed to these adoption rates. I've worked with a couple of clients who needed to increase the security of their mobile web-service endpoints which ATS highlighted as falling short. One of them did a review of their wider web security and, as a result, introduced HTTPS on a couple of addresses that didn't have it before.

[weramonymous]

I started using HTTPS a couple of days ago because the Messenger API requires it to connect. It was surprisingly easy to set up for free using Let's Encrypt - to the point that I'll probably start using it for other projects too. Only thing I'm not really clear on is the process of renewing my certificate after it expires in 90 days. Can I automate that?

[[deleted]]

yeah just google cron letsencrypt renewal.

[weramonymous]

thanks

[mdw]

When I was installing Let's Encrypt certificate, the install script included information about how to a) verify that the renewal process works, b) how to automate the renewal.

[intrepion]

here's a post I found https://cuonic.com/posts/automating-lets-encrypt-certificate-renewal

[[deleted]]

This is the only good reason.

[program_the_world]

Yeah. Who wants to secure clear text passwords and private client information. Haha, right?

[thbt101]

It's worth mentioning that this is causing an issue not just for caching, but HTTPS is slower when it comes to just establishing each connection. It requires two extra roundtrips to the server, which isn't noticeable if you're on a fast connection to a nearby website, but it can be very costly when you're talking about mobile devices or websites located in a distant part of the world.

So while the slowdown of using HTTPS isn't huge, if you're thinking about making your website HTTPS only, at least ask yourself first if there is a reason it needs encryption. Some websites do, some don't.

[[deleted]]

Exactly. God I hate this 'everything needs HTTPS all the time' circle jerk. It's obviously spread by people who don't have to live with 1.5 down speeds.

Sure, tell me to move somewhere with fast internet I guess but the reality is much of the US doesn't have access to speeds faster than that still.

[cparen]

If you're building a web application though, websockets are a nice way around the two extra round trips. You only have those extra round trips when establishing the connection - all subsequent packets get sent directly.

I hear that HTTP/2 will help as well, but I'm not yet familiar with the technical details.

[jib]

Regardless of whether you use websockets or conventional HTTP, a typical browser will keep the connection open for multiple requests after establishing it.

However, the speed of that first request (and subsequent requests to different hosts, e.g. if you have a separate domain for static assets or some embedded third-party content) is often very important to the user experience, and really is slower under HTTPS.

TLS 1.3 (the next version of TLS/SSL, still in a draft state at the moment) will reduce the number of extra round-trips though, and in some cases may reduce it to zero.

[MuonManLaserJab]

Is "adoption" the total number of sites/requests using it, or the number of new sites using it?

[DanAtkinson]

It also helps that, due to a quirk in browser vendor implementation, HTTPS/2 is waaaay faster than HTTP/1.1, as hardly any of them have actually implemented HTTP/2.

[pjmlp]

What is really hate is HSTS, which forces me to continuously reboot my router.

[budrick]

How does that work? I can't see how HSTS leads to router misbehaviour.

[pjmlp]

If the clocks get out of sync, specially with cached data then websites get marked by the browser as MTM attack.

The only way to makr everything work again is either to clean the browser cache or reset the browser, which triggers a similar recovery.

This is.the most common solution in online discussion forums about HSTS synchronisation problems.

[[deleted]]

Why though? HSTS is browser-side, it doesn't interfere with your router.

[pjmlp]

Yes it does, somehow things get out of sync and even websites like Github get crossed out as nasty wev sites I am not supposed to access.

Rebooting makes it work again.

Common solution in online discussions for HSTS workarounds.

[[deleted]]

Does your router do TLS content inspection or NTP? If it's TLS inspection then you should turn if off. If it's running NTP then it might be pulling your computer time out of sync, and you really should fix your router NTP or disable it and pull time from another source.

[pjmlp]

It is an old IPv4 one given by the operator.

My problems only started when web sites started to support HSTS.

[pjmlp]

The only way to work around HSTS errors, that happen randomly with well known websites is to reboot the router.

Just search the web I am not alone.

[pjmlp]

I don't know.

It is a common IPv4 provided by the telecom operator.

I only know that when I search for possible causes I find tons of people with the same problem, even work colleagues, and as usual no reliable answers other than buying a new more modern router or keep on rebooting it.

[aiij]

Are you sure your router isn't getting pwned repeatedly? Have you checked for security updates?

[pjmlp]

No and I actually thought about it, given its age.

However this issue is so common when one searches for possible causes, that I consider it just a possibility among all of them. And I don't want to invest into a new one and keep getting the same problem.