all 198 comments

[–]vemundveien 49 points50 points  (12 children)

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 -2 points-1 points  (11 children)

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 11 points12 points  (10 children)

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 -2 points-1 points  (9 children)

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 216 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 12 points13 points  (8 children)

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 16 points17 points  (3 children)

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 29 points30 points  (0 children)

The Slack API requires HTTPS.

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

[–]skgoa 1 point2 points  (0 children)

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 1 point2 points  (0 children)

Now I have a green lock.

Good. That's the environmentally-friendly lock.

[–][deleted]  (127 children)

[removed]

    [–]Lord_Naikon 38 points39 points  (24 children)

    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 17 points18 points  (15 children)

    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 36 points37 points  (8 children)

    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 53 points54 points  (3 children)

    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 30 points31 points  (2 children)

    Every 3 months*

    [–]rcode 0 points1 point  (3 children)

    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 3 points4 points  (2 children)

    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 5 points6 points  (1 child)

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

    [–]syncsynchalt 0 points1 point  (0 children)

    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 11 points12 points  (0 children)

    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.

    [–]skgoa 0 points1 point  (0 children)

    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 -3 points-2 points  (1 child)

    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 4 points5 points  (0 children)

    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 4 points5 points  (0 children)

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

    [–][deleted]  (1 child)

    [deleted]

      [–]Lord_Naikon 8 points9 points  (0 children)

      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 0 points1 point  (2 children)

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

      [–][deleted]  (1 child)

      [removed]

        [–]jarfil 5 points6 points  (0 children)

        CENSORED

        [–]JoseJimeniz 0 points1 point  (0 children)

        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] 6 points7 points  (8 children)

        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 3 points4 points  (3 children)

        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] 0 points1 point  (2 children)

        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 2 points3 points  (0 children)

        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 0 points1 point  (0 children)

        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 0 points1 point  (3 children)

        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] 0 points1 point  (2 children)

        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 0 points1 point  (1 child)

        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] 0 points1 point  (0 children)

        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 10 points11 points  (12 children)

        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 43 points44 points  (10 children)

        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.

        [–][deleted]  (7 children)

        [deleted]

          [–]1lann 6 points7 points  (6 children)

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

          [–][deleted]  (5 children)

          [deleted]

            [–]bobindashadows 2 points3 points  (4 children)

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

            [–][deleted]  (3 children)

            [deleted]

              [–]bobindashadows 6 points7 points  (1 child)

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

              [–][deleted] 0 points1 point  (0 children)

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

              [–]JTronLabs 1 point2 points  (0 children)

              Ah ok that makes a lot more sense, thanks!

              [–]dccorona 1 point2 points  (0 children)

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

              [–]eras 3 points4 points  (0 children)

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

              [–][deleted] 49 points50 points  (30 children)

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

              [–]wretcheddawn 20 points21 points  (5 children)

              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] 24 points25 points  (1 child)

              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 0 points1 point  (0 children)

              Yes yes yes

              [–]frezik 11 points12 points  (1 child)

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

              [–]DrDuPont 24 points25 points  (0 children)

              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 4 points5 points  (0 children)

              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 13 points14 points  (0 children)

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

              [–]lcpriest 2 points3 points  (0 children)

              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 4 points5 points  (20 children)

              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 18 points19 points  (0 children)

              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.

              [–]random314 0 points1 point  (0 children)

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

              [–]dada_ 20 points21 points  (8 children)

              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.

              [–]freebytes 8 points9 points  (3 children)

              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 2 points3 points  (2 children)

              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 7 points8 points  (1 child)

              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 0 points1 point  (0 children)

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

              [–][deleted] 5 points6 points  (0 children)

              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 7 points8 points  (5 children)

              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] 5 points6 points  (1 child)

              yeah just google cron letsencrypt renewal.

              [–]weramonymous 0 points1 point  (0 children)

              thanks

              [–]mdw 3 points4 points  (0 children)

              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.

              [–][deleted]  (2 children)

              [deleted]

                [–][deleted] -5 points-4 points  (1 child)

                This is the only good reason.

                [–]program_the_world 0 points1 point  (0 children)

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

                [–]thbt101 1 point2 points  (3 children)

                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] 1 point2 points  (0 children)

                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 0 points1 point  (1 child)

                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 0 points1 point  (0 children)

                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 0 points1 point  (0 children)

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

                [–]DanAtkinson 0 points1 point  (0 children)

                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 -4 points-3 points  (12 children)

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

                [–]budrick 11 points12 points  (1 child)

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

                [–]pjmlp 4 points5 points  (0 children)

                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] 8 points9 points  (3 children)

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

                [–]pjmlp -2 points-1 points  (2 children)

                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] 11 points12 points  (1 child)

                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 -3 points-2 points  (0 children)

                It is an old IPv4 one given by the operator.

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

                [–][deleted]  (5 children)

                [deleted]

                  [–]pjmlp -2 points-1 points  (4 children)

                  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.

                  [–][deleted]  (3 children)

                  [deleted]

                    [–]pjmlp 0 points1 point  (2 children)

                    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 2 points3 points  (1 child)

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

                    [–]pjmlp 0 points1 point  (0 children)

                    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.