pde3

Yes, there are definitely multiple ways to configure it. We focused first on working successfully for as many people as possible, which meant shipping the letsencrypt-auto wrapper script which requires sudo.

But with some extra work you can definitely run Certbot as a non-root user, and we're working with the OSes that package us to have Certbot operate with something like ssl-cert group privileges in many situations in the future.

I think your criticisms were pretty fair of the earliest releases of the Let's Encrypt client, but they seem to be less accurate now. We see the client (aka Certbot) being used successfully by many hundreds of thousands of site operators. In terms of full automation, the Apache plugin has gone from "experimental" to "works for most people automatically". We'll be working on delivering similar features for Nginx next.

But if lego works for you; that's great!

Oh, and it's in use on 500K - 1 million webservers. So extra eyes auditing it are always welcome :)

certbot-auto (previously known as letsencrypt-auto) is definitely a hack -- it allows people to run the client on typically older OSes that don't have backported native packages. It's basically a tiny autoupdate and packaging system written in bash and python. It uses airgapped signatures for updates, checks sha256 hashes for all of the python dependencies it's installing, and puts them into a python virtual environment so that they don't affect your OS.

If you don't like wget; chmod, you can check a gpg signature too: https://certbot.eff.org/docs/intro.html#installation

https://github.com/certbot/certbot/issues/2373 (if you want to reuse a CSR; reusing the key is probably easier)

The official client (now Certbot) actually supports a whole bunch of different use cases; some people want full automation of everything; other people find that "invasive". The software supports both, but people would often find the wrong instructions. The new Certbot landing page tries to do a much better job of giving people instructions that are tailored to their use case and needs. Please try it and send us feedback!

https://certbot.eff.org

If you use the letsencrypt python client with "certonly --webroot", it will never touch your config files at all. You can add "-n" to make everything non-interactive and command line-only.

If you use letsencrypt with "certonly --apache" (or --nginx, when the nginx plugin is released) it will make only transient changes to your config in order to obtain the cert, and then restore it to the original state before exiting.

If you use letsencrypt with "run" (which is the default command) it will make config changes if those appear to be necessary for installing the cert.

One challenge we've had is how to design the command line interface to ensure that the users who want maximum automation get it, and the users who want maximum manual control also get that. Both set of behaviour are available.

You're right, even with Let's Encrypt HTTPS is still more work than speaking insecure HTTP. But it's a brand new project, and we're working to ensure the amount of effort involved is monotonically decreasing.

In the next few months we'll be shipping an Nginx installer plugin and model renewal scripts for operating systems to provide native automated renewal with their packages of the client. Both of those should help to reduce the amount of work for your use case!

> That was weird, the no-js version didn't work. It just sat there spinning.

What extensions do you have installed? There's a known and unfixable issue with browsers that both block JS and absolutely block all requests to tracking domains (eg AdAway, which modifies /etc/hosts).

> What, why would I unblock those?

To incentivise better behaviour by web publishers and advertisers!

Spoofing your user agent on your own typically makes you easier to fingerprint, not harder. See footnote 3 of the Panopticlick 1.0 paper: https://panopticlick.eff.org/static/browser-uniqueness.pdf

It's more plausible for a large population of browsers to share a single spoofed user agent; all of the Tor Browsers pretend to be a single specific version of Firefox for Windows.

It's arguably true that we set out to build some of the more complicated pieces of the client first, when we could have tried with simpler versions that simply ignored important parts of the HTTPS deployment task.

But the traditional UNIX philosophy has not been working well for TLS to date, and certificates are hard to do right in a simple way. If every web developer and sys admin needs to know about the following things:

- how to get a cert from us - how to bind a privileged port (:80 or :443) or reconfigure a webserver to prove domain control - the difference between end-entity certificates, CA certificate chains, "combined" end-entity and CA chains, and the weird heisenbugs you can get by getting them mixed up - how to handle the need to renew certificates periodically - the HTTP secure cookie flag - the HSTS header - redirects from HTTP to HTTPS - the Content-Security-Policy: upgrade-insecure-requests directive - OCSP stapling - the tradeoffs involved in ciphersuite tuning

Then we are never going to have a universally encrypted and secure Web.

So we set out to build a client that will, as it matures, get all of those things right for you. Meanwhile, the Python client does support console-only (-t) or non-interactive (pass in flags to avoid all questions) modes of operation.

As we get to a 1.0 release, we expect those modes will be more robust and documented / discoverable for those who want them. But we think that many web developers will be happier to not have to know the difference between a cert, a cert chain, and a full chain.

ublock is great software (it didn't exist when we started work on PB!) and so there are only a few things PB will catch that it doesn't. But there are some. For instance, PB will replace widgets such as Tweet and Facebook like buttons with locally hosted, non-tracking variants. And PB may catch new trackers faster than ublock because it uses algorithmic detection rather than requiring a blocklist.

As many as we can implement! Pull requests are welcome :)

Good starting places for the current heuristics:

https://github.com/EFForg/privacybadgerchrome/blob/stable/sr...

https://github.com/EFForg/privacybadgerchrome/blob/master/sr... https://github.com/EFForg/privacybadgerchrome/blob/stable/sr...

In the US, consider Credo Mobile or T-Mobile. Even AT&T discontinued this practice when called out on it, while Verizon's is flatly recalcitrant; their privacy policy says, "If you do not want information to be collected for marketing purposes from services such as the Verizon Wireless Mobile Internet services, you should not use those particular services."

This is a question about the policy layer of the CA using the ACME protocol.

The previous issuing CA should have revoked the cert they issued when the domain was transferred. But a CA speaking the ACME protocol might choose to look at whois and DNS for additional information to decide whether it issues different challenges in response to a certification request.

Those free certs will encrypt from the browser to CloudFlare's CDN. You still need to do something to encrypt from CloudFlare to the publishing webserver. Self-signing can work for that hop, though Let's Encrypt may wind up being smoother for sys admins.

We've been working with CloudFlare to drive HTTPS adoption, and plan to work with them further on integration.

The CAs have agreed to stop using SHA-1 by 2016, and Let's Encrypt will launch with something stronger on day one.

But SHA-1 attacks are going to be a huge problem all over our protocol stack :(

We'll be in a position to deploy defenses like pinning (http://www.ietf.org/id/draft-ietf-websec-key-pinning-21.txt) for site operators who want more protection against the structural problems of the CA system. That will need to be implemented with care, but it should be possible.

Let's Encrypt is going to publish records of everything it signs, either with Certificate Transparency or some other mechanism.

Browsers will be able to check any cert signed by the Let's Encrypt CA against the published list. If there's a discrepancy, that will be immediately detectable.

You're absolutely right. From first principles, HTTP should have a louder warning than self-signed HTTPS.

Our hope is that Let's Encrypt will reduce the barriers to CA-signed HTTPS sufficiently, that it will become realistic for browsers to show warning indicators on HTTP.

If they did that today, millions of sites would complain, "why are you forcing us to pay money to CAs, and deal with the incredible headache of cert installation and management?". With Let's Encrypt, the browsers can point to a simple, single-command solution.

This is just a pre-announcement to let folks (OSes, hosting providers, other platforms) plan and do integration work. Per our own warnings, we definitely don't want this running on production machines until it launches in 2015.

Our Apache code is a developer preview, we'll be working on Nginx next.

ISRG will be operating a new root CA for this project. Although if you think that your choice of CA makes you more or less secure, you may not have understood how PKIX works -- you can buy a cert from whichever CA you like, but your adversary can always pick the weakest one to try to impersonate you.

Sorry, I tried to reply here yesterday but was rate-limited out of the conversation :/

Our aim with this project is to not give advice about what works "right now", because we aren't convinced there are any secure messaging options right now, especially when the usability dimensions of security are taken seriously.

Instead, what we're trying to do is articulate the things that both large companies and open source projects need to be doing to move in the right direction.

Since this is phase 1 of a multi-part campaign, we're going to take a closer look at the usability and further security properties of tools that are doing well on the Scorecard in subsequent phases.

On Skype, before launch it wasn't clear clear to us whether the NSA's reported Skype intercept capability came from breaking or having Microsoft backdoor the crypto (which would mean they loose the second checkmark) or by having Microsoft hand out a false public key for the other party (which is possible due to the lack of a check mark in the third column). We have an ongoing conversation with Microsoft about this and are reviewing Skype's ratings at the moment.

It wasn't clear to us whether the NSA intercepts Skype by breaking the crypto, or by compelling injection of false public keys in order to perform a man in the middle attack. In the latter case it's the third checkmark (lack of ability to verify keys) that's their users' undoing. We're talking to Microsoft about that at the moment, and may revise that entry.

There's a weird case around iMessage and any tool that is provided by an OS vendor. I think we need to add a note about this, but in those cases that company could inject malware or a backdoor either in the messaging system or somewhere else in the OS. Since we're trying to tackle one hard problem at a time (secure messaging but not secure operating systems and software distribution) there should be an extra caveat about offerings from OS vendors.

The only tool that gives strong metadata protection right now is Pond, and we aren't listing unusable tools that aren't out of beta yet. We considered but haven't yet included bitmessage for the same reason.

For the record, we aren't endorsing CryptoCat or any of the other tools that got 7/7: ChatSecure, TextSecure, Signal/RedPhone, SilentText, SilentPhone, or the ones that are close like Pidgin+OTR, Subrosa, Surespot, Telegram, Threema or iMessage.

Getting those scores is a sign that those projects are taking the right approach. Lots of codebases have horrific bugs, including OpenSSL, older versions of the SSL and TLS protocol itself. We believe that focusing the community on the task of moving the best projects forward is more constructive than

Testing the tools that are scoring highest for usability, and doing deeper examinations of their designs and codebases, is going to be a future component of this campaign.

That's why we view this Scorecard as the opening in a campaign to evaluate both the usability and security of messaging tools. Traditional cipherpunk designs are unusable by humans, and a lot more work is going to be needed to build things that can have hundreds of millions of users and be secure at the same time.

Some extra info for commenters in this thread:

This Scorecard is phase 1 of our multi-stage campaign for Secure and Usable Crypto. We believe these criteria are necessary for any strong security tool, though meeting them doesn't guarantee that a system is perfect.

Subsequent phases of the project will focus on usability (which is a huge problem for activists and journalists who try to use encryption), metadata protection, openness and federatability of protocols, and much deeper audits of the design and implementation security of the software that is scoring highest.

We do have experts reviewing them. Which items are false?