Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Electronic Frontier Foundation Communications Encryption Privacy Security Social Networks The Internet

Let's Encrypt Is Now In Public Beta (eff.org) 135

Posted by timothy from the first-person-plural dept.
Peter Eckersley writes: As of today, Let's Encrypt is in Public Beta. If you're comfortable running beta software that may have a few bugs and rough edges, you can use it to instantly obtain and install certificates for any HTTPS website or TLS service. You can find installation instructions here.
This discussion has been archived. No new comments can be posted.

Let's Encrypt Is Now In Public Beta More

Let's Encrypt Is Now In Public Beta

Comments Filter:

  • Almost as good as unicode support here

  • Shared hosting (Score:3)

    by tepples ( 727027 ) <.tepples. .at. .gmail.com.> on Thursday December 03, 2015 @03:33PM (#51052347) Homepage Journal

    From Introduction [readthedocs.org]:

    The client requires root access

    Because a shared web hosting customer is not root, the hosting provider will have to install Let's Encrypt on behalf of its customers. I plan to open a support ticket with my hosting provider to request installation of Let's Encrypt. What are the most likely objections that a hosting provider might have to enabling this?

    • expect lack of interest due to no interest from other customers. therefore unwillingness to invest people-time into testing this.

      i suspect your provider will simply tell you to go to startssl and get yourself a free ssl certificate.

    • Yep. Got this same problem. Very interested, but need it to work through CPanel ideally or at least WHM.

    • Re: (Score:1)

      by Anonymous Coward

      Beta software that requires root access. What could possibly go wrong?

    • >> What are the most likely objections that a hosting provider might have to enabling this?

      I know one of mine (HostGator) threw a fit (charged me for installation) when I got my X.509 server cert from another provider.

      I suspect many of them were looking forward to the brave new world of "HTTPS by default" as a big money-maker and aren't too pleased with the fact that the consumer's price for certs has already been driven down to $0.

    • It does require root if you want it to run a private port 80/443 service to do the authentication for you and/or to install the certificate into your apache config on your behalf. A nice feature for less capable users (ain't that a scary though)

      But if you are using an existing web server and are okay with manual certificate installation/configuration and have a long command-line full of path overrides (eg. no using /etc for storing the generated certs) then it runs just fins as a normal user. I did it durin

    • Because it's a bad idea? Two independent purposes are served by HTTPS - encryption in transit, and sender identification. Self generated certificate is enough to do the encryption in transit business.

      For sender identification, it makes no sense to do it automatically and/or cheaply. It should be even more expensive, and come with lots of verifications. By doing it "automatically", we defeat the whole purpose of sender identification.

      Browsers (including a partner in this project- Mozilla) are too stupid to n

      • Re: (Score:3)

        by tepples ( 727027 )

        Let's Encrypt already validates that the sender is authorized to speak for the domain. But you make it sound like there's no place for encryption in transit without stronger sender identification, ideally one verified against real-world credentials. Further, you make it sound like there ought to be an entry barrier to sender identification. Do I understand you correctly so far? And if so, how much ought the right to send to cost, in your opinion? Should individuals have the right to send, outside the course

        • But you make it sound like there's no place for encryption in transit without stronger sender identification

          I am saying the opposite, no idea why you interpret it this way. It is very easy to encrypt in transit - just generate your certificate and encrypt away. Even the name of the project - Let's Encrypt - "makes it sound like" encryption in transit is the big deal, not the sender identification.

          Repeat after me - encryption DOES NOT NEED identification.

          Further, you make it sound like there ought to be an entry barrier to sender identification

          How do you identify something without creating a barrier for it?

          Do I understand you correctly so far?

          50%.

          Should individuals have the right to send, outside the course of a business?

          Send away, no problem.Want to send encrypted? Generate a certificate and send away, no problem

          • Thank you for explaining. Consider three different attacks on an HTTP session: passive sniffing, active proxying by a man in the middle, and typosquatting. HTTPS with a self-signed certificate solves the first. HTTPS with a domain-validated certificate solves the first two. HTTPS with an organization-validated certificate solves all three.

            Want to send encrypted? Generate a certificate and send away, no problem there either.

            This resists passive attacks but not MITM or typosquatting. Traditionally, web browsers that support HTTPS have set the bar at MITM.

            Want someone to vouch for you that you are the sender you pretend to be? Ouch, that will be $x - not because it is a prerogative of the rich, but we need to do the following verifications which cost $x.

            That depends on whether you define atta

            • Thank you for explaining. Consider three different attacks on an HTTP session: passive sniffing, active proxying by a man in the middle, and typosquatting

              There is a fourth one - phishing. You might call it a variant of typo-squatting, but actually it is not. Your attempt to call it social engineering will also be met with a "Nah".

              You get an email about updating your ING bank contact details urgently, and get a link to click on directly. But it is ingatyourservice.com - page content look and feel copied from ING's net banking website. User doesn't notice that this is not real ING, ignores the few mistakes in copying the phishers made, and enters everything th

              • Re: (Score:2)

                by tepples ( 727027 )

                There is a fourth one - phishing. You might call it a variant of typo-squatting, but actually it is not.

                Phishing is similar to typosquatting in that the user is being redirected to the wrong domain. I agree that an organization-validated cert protects against this, especially among novice users who can't be trusted to stick to bookmarks. But a domain-validated cert might be enough if credentials aren't valuable enough to allow rapid irreparable damage before blocking the account, such as a forum or wiki account compared to a bank account.

                There is a fifth attack vector - though none of the business of website owners or visitors. But EFF has made it their business to complain about it. It is the dragnet surveillance by TLAs. HTTPS prevents that too. "Let's Encrypt" sounds like an attack on that attack.

                This counts as passive sniffing and occasionally MITM.

                both - banks' padlock icon and Joe Sixpack's website's padlock icon look the same to me.

                On Pin Eight [pineight.com], whic

                • This counts as passive sniffing and occasionally MITM.

                  MITM is too much work for dragnet. But yeah, passive sniffing.

                  On Pin Eight, which uses a domain-validated certificate, Firefox shows me only a green lock. On Chase, which uses an organization-validated certificate with EV extensions, Firefox shows me a green lock plus "JPMorgan Chase & Co." in green.

                  You're right, I notice that now. But distinction is not big enough for the people who will get scammed by the phishing. And I remember emails from my bank a few years ago about looking for the padlock icon - this distinction wasn't made there.

                  So it remains a bad idea - insufficiently validated websites getting that padlock, getting more people to be phished. All due to conflating encryption and sender validation.

                  • Re: (Score:2)

                    by tepples ( 727027 )

                    "A site doesn't need MITM protection unless it also needs phishing protection." Are you claiming or not claiming this?

                    MITM is too much work for dragnet.

                    Yet MITM is common on corporate networks.

                    And I remember emails from my bank a few years ago about looking for the padlock icon

                    It depends on how long ago was "a few years ago". Was it before the introduction of extended validation [wikipedia.org]? If so, browsers might not yet have introduced UI to distinguish domain- from organization-validated certificates.

                    So it remains a bad idea - insufficiently validated websites getting that padlock, getting more people to be phished.

                    For a web site operated by an individual as a hobby, where the operator desires protection from passive and MITM attacks, what measures

                    • Thanks to you, I learnt about EV certificates.

                      "A site doesn't need MITM protection unless it also needs phishing protection."

                      Everyone "needs" all kinds of protection, but different people pay for different ones. MITM is used in a way of phishing, so you cannot protect against phishing unless you also protect from MITM . But if certificates are a dime a dozen, you've not really protected from MITM phishing as well as impersonation phishing. You're only achieving the encryption in transit, and preventing the

                    • Re: (Score:2)

                      by tepples ( 727027 )

                      But if certificates are a dime a dozen, you've not really protected from MITM phishing as well as impersonation phishing.

                      Then let me reword my perception of your central thesis one more time: "It is not worth making a certificate that protects against impersonation of a domain owner using the same domain unless it is also worth paying for a certificate that protects against impersonation of a business using a different domain." Do I have it right now?

                    • It is not worth making a certificate that protects against impersonation of a domain owner using the same domain unless it is also worth paying for a certificate that protects against impersonation of a business using a different domain

                      Depends on the ease of attack. One way I see for same domain impersonation is by compromising the user's DNS. Are there others? DNS compromise is somewhat involved but not extremely difficult, not very common in my experience with novice users, nor in the news I read.
                      But you are right, in that this attack vector definitely cannot be ignored, so it is worth making a certificate to protect against the same domain attack.

                      So does it boil down to Let's Encrypt being a protection against DNS compromises?

                    • Re: (Score:2)

                      by tepples ( 727027 )

                      So does it boil down to Let's Encrypt being a protection against DNS compromises?

                      Until all domains' DNS servers are upgraded to support DNSSEC and all web browsers are upgraded to support DANE, half of what a DV cert does is defend against DNS spoofing on a user's first visit. The other half is a protection against transparent proxying.

          • Remember banks are relying on the "HTTPS" lock icon and instructing their users to look for it and consider themselves "safe" if it exists. ING bank shouldn't have to buy ing.com, ing.org, mying.com, ingbank.com, myingbank.com just because domain ownership is the be all and end all of "identification" on the internet.

            This is why you should expect EV-SSL [wikipedia.org] from your bank. There is plenty of additional paperwork required to prove identity and it gives additional assurance with a different icon in the browser address bar.

            • I think bingoUV's point is that novice users do not know what to look for to tell the difference between DV and EV certificates. The icon is the same either way: a lock for DV or a lock and business name for EV. Novices don't know to look for the business name because they haven't been taught so, as back when TLS proponents were first saying "look for the lock", EV didn't exist.

  • Very short certs. (Score:5, Insightful)

    by gantzm ( 212617 ) on Thursday December 03, 2015 @03:34PM (#51052353)

    They really want you to automate this. From the web site:

    Let’s Encrypt CA issues short lived certificates (90 days). Make sure you renew the certificates at least once in 3 months.

  • I was looking forward to this... (Score:5, Insightful)

    by jez9999 ( 618189 ) on Thursday December 03, 2015 @03:47PM (#51052467) Homepage Journal

    Unfortunately, their MAXIMUM length of certificate is 90 days and it ain't getting longer; if anything they want to make them shorter in duration. So anyone who doesn't want to or can't, for whatever reason, run some cronjob on their server to auto-renew their certificates should give these guys a miss. Great shame that they let their "automate everything or GTFO" ideology override many people's legitimate need or desire for annual certificates.

    • Re: (Score:3)

      by darkain ( 749283 )

      If they don't fit your needs, vote with your dollars. You're more that free to pay for certs from another organization!

      On that note: I initially had some issues with part of their implementation, too. But I'm working through it now by having a dedicated VM just for renewing my certs, and then that VM's cron script pushes the cert files to the actual web servers.

      It isn't that difficult to work around the limitations on their system right now if you just put a little thought into it.

      • Re: (Score:2)

        by jez9999 ( 618189 )

        Oh don't worry, I am voting with my (non-)dollars. I've just signed up for some more annual certs from StartCom. LetsEncrypt and their stubborn attitude can go hang. It's just disappointing, that's all.

        • Re: (Score:2)

          by jopsen ( 885607 )
          Why should they work to provide the same as StartCom, seriously...

          The whole LetsEncrypt thing is about making the internet more secure. In all honesty long lived certificates is not a good idea. Because most CAs have your certs expire once a year, many people don't automate certificate renewal.
          But we should, just like we should rotate passwords, etc... (I know it's not the same).

          Obviously, LetsEncrypt won't fit in with most existing setups. Hopefully, shared hosting providers will pick it up and integr
        • What browsers have start.com in their default CA list?

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      It's probably the right decision though, because certificate revocation is terminally broken. Short-lived certificates are the only option to ensure that the expected audience won't have effectively irrevocable certificates floating around for years after losing control over the keys in a configuration mishap.

      However, I am certainly not going to trust them with root access to the server, partly because I don't have it myself, and partly because that should not be necessary at all.

      • Re: (Score:1)

        by Anonymous Coward

        You can run the LE auto-update software as a non-root user. It takes some thought, but it's 100% doable.

    • Re: (Score:1)

      by Anonymous Coward

      1) There are some pretty compelling reasons for choosing the 90-day cert expiry period: https://letsencrypt.org/2015/11/09/why-90-days.html

      2) You don't have to run the official LE client. ACME is fully documented and at least one fully-functioning alternative client is out there. Given that LE entered public beta *today*, expect many more ACME clients in the near future.

      3) ...who *needs* CA-issued TLS certs that have a 365 day expiry period? Far-flung embedded devices that don't even have the horsepower to

  • I'm all about free certs - but what kind of general support will there be? The last thing I want to do is tell my mom that her Android tablet can't connect to my web server because Chrome for Android won't trust the connection and won't give her the option to add an exception...

    • Re: (Score:1)

      by Anonymous Coward

      Their root cert is cross signed by another big time CA, which is trusted by all the major browsers.

    • From: http://lwn.net/Articles/664385... [lwn.net] It is hosted by the Linux Foundation and sponsored by the Electronic Frontier Foundation, Mozilla, Cisco, and Akamai. Let's Encrypt also has a cooperation agreement with the certificate authority Identrust, which will sign the Let's Encrypt intermediate certificate. This cross-signature from an existing certificate authority will guarantee that the Let's Encrypt certificates will be accepted by all major web browsers.

      • Re: (Score:2)

        by tepples ( 727027 )

        Or, to put it shorter, "Let's Encrypt is an Identrust reseller."

        • No, because it really is Let's Encrypt that signs the certificates, not IdenTrust. IdenTrust has only signed the intermediate certificates that allows Let's Encrypt to be trusted until their own root has made it into most trust stores.

      • Why would a CA authority cross sign a competitors certificate , and kill their own business ? That I don't get

  • With access to my server's private keys. Who does this sound like a good idea to?

    • So inspect the code before you run it. It's open source, written in Python.

      • It has automated updates built in and is pretty much required to be fully automated to be useful. So I would have to disable those updates until they break it from working then re audit the code again and hope to catch that break before the SSL cert expires. That is a whole lot of work and risk.

        Now you could just grab a new expiration date cert via the same certificate request and not need to know the private key in the first place ever but that does not look like how this works it expects to have a free

        • It has automated updates built in and is pretty much required to be fully automated to be useful. So I would have to disable those updates until they break it from working then re audit the code again and hope to catch that break before the SSL cert expires.

          So why must you audit the code? Can't you simply trust the guys to not deliver malicious code? Do you not think that they are at your side? Why be part of anything in the first place if you can't trust the makers?

          • The code should only need to ready the private key one time during the initial setup. A Cert request is not dated and has no sensitive information and can be reused to get a new cert until the private key changes. Pretty much this is one tool that should be two, one to setup with no need for network access (it creates a priv key a cert request configures other servers) and another that does the every 90 days or more often updates.

    • Those who don't have the skills to do it otherwise? It is of no use to any other kinds of people anyway.

  • Honest question -- why would you want a cert you have to renew every 90 days? In case it gets stolen? I guess I just don't understand the point.

    • Re:But Why? (Score:5, Informative)

      by blackiner ( 2787381 ) on Thursday December 03, 2015 @04:20PM (#51052725)
      There is a pretty writeup about modern TLS issues on lwn: http://lwn.net/Articles/664385... [lwn.net]
      It seems that certificate revocation is not working particularly well in practice. The 90 day duration is meant to help with this, you can simply let the certificate expire.

      • They want you to enable HSTS for long duration (1 year), with certificates that expire in a week so that when you mess with the authorities and don't comply with their demands, they are able to wipe you off of the Internet faster.

    • There are so many certs now that revocation isn't working as nice as it used to be. It used to be that the user-agent would actually download a complete list of revoked certificates to compare against. That's not really viable so OCSP is used instead. Short-lived certs simply it since we only need to care about revoked certs for a more limited time, and it also encourages automation.

    • Re:But Why? (Score:5, Informative)

      by itsdapead ( 734413 ) on Thursday December 03, 2015 @04:58PM (#51053017)

      Bear in mind that current free certificates from the likes of StartSSL expire after 1 year anyway - and are at least 4 times more hassle to obtain and install than Lets Encrypt is shaping up to be.

      • Today I went through the StartSSL process to renew the certificate for a site because it'll more than likely expire before my hosting company has a chance to implement Let's Encrypt. StartSSL isn't really that different from GoDaddy, except for two things: you use a client certificate instead of a password to identify yourself, and verifying domain control and issuing the cert are split into two steps. One e-mail verification to get your individual client cert, another to verify the domain, then paste in th

  • Nothing for windows, kind of a disappointing way for the EFF to severely limit their audience.

    • Re: (Score:2)

      by BiOFH ( 267622 )

      With Windows running only 27% of the Internet's web servers*, calling it "severely limit[ing]" is more than a little hyperbolic.

      * source: http://news.netcraft.com/archi... [netcraft.com]

      • Back in the day we web devs would be regularly told that only targeting 97% of visitors through only supporting IE was not good enough, and that 3% counted...

        On that basis, 27% of market share is a little more to worry about.

Slashdot Top Deals

Beware of all enterprises that require new clothes, and not rather a new wearer of clothes. -- Henry David Thoreau

Close