Jump to content
Our Domain Name Has Changed! Read more... ×
alt3rn1ty

Free site encryption - Lets Encrypt

Recommended Posts

Arthmoor dont know if you are interested but something nice is coming in September

 

https://letsencrypt.org/

 

Apparently the process is very simple once its set in motion. Free site encryption .. No strings.

 

Let’s Encrypt is a free, automated, and open certificate authority brought to you by the Internet Security Research Group (ISRG).

 

https://letsencrypt.org/howitworks/

 

Anyone who has gone through the trouble of setting up a secure website knows what a hassle getting a certificate can be. Let’s Encrypt automates away all this pain and lets site operators turn on HTTPS with a single click or shell command.

When Let’s Encrypt launches in September 2015, enabling HTTPS for your site will be as easy as installing a small piece of certificate management software on the server:

$ sudo apt-get install lets-encrypt

$ lets-encrypt example.com

That’s all there is to it! https://example.comis immediately live.

The Let’s Encrypt management software will:

  • Automatically prove to the Let’s Encrypt CA that you control the website
  • Obtain a browser-trusted certificate and set it up on your web server
  • Keep track of when your certificate is going to expire, and automatically renew it
  • Help you revoke the certificate if that ever becomes necessary.

No validation emails, no complicated configuration editing, no expired certificates breaking your website. And of course, because Let’s Encrypt provides certificates for free, no need to arrange payment.

Share this post


Link to post
Share on other sites

Painless SSL? Are we living in a dream now? :P

 

Looks like a cool idea. Will have to remember to check it out when they go live.

Share this post


Link to post
Share on other sites

Giving this a bump.

Of all the login data stored in my vault, AFK mods is one of the last non fully https encrypted sites i visit, with the others either going full encryption (Neverwintervault and hopefully the nexus, too after its redesign) or closing down this summer (bethsoft).

Share this post


Link to post
Share on other sites

Not ignoring you btw. Just don't have a lot of time to mess around with something like that right now. It doesn't seem to be something considered overly important by any of the forums I visit regularly whether they're modding forums or otherwise so I'm not sure it would end up being worth the hassle.

 

We'd need to set up a clone of the site to test it and make sure nothing was going to break etc. This isn't something you just turn on blindly and hope for the best.

Share this post


Link to post
Share on other sites

Glad you implemented this eventually, especially with Google and Chrome steering the internet towards SSL everywhere.

MUTC8Yz.png

I only recommended it after seeing Steve Gibsons investigation into LetsEncrypt on Security Now.

Here's what he had to say before it took off - Security Now #483 :

https://twit.tv/shows/security-now/episodes/483?autostart=false

( Go to - Time 1:14:00 )

 

Was it as painless / trouble free as they claim ?

 

Steve: They put - yes. And I've now read the entire specification front to back, 36-page
RFC, and they've nailed it. They absolutely got it right. But it is crucial to understand
what it is that you get for free. It is absolutely the case that you get for free what many
certificate authorities are now charging for. So in that sense it is absolutely true
competition for what all certificate authorities are currently making some money selling.
It is not at all competitive with what all certificate authorities should be charging money
for, meaning that it is - okay.
And so what that is: Remember that there are broadly three categories of certificate.
There's the so-called domain validation certificate, a DV, which its only assertion is that
the certificate is bound to this domain, that is, the certificate is just a certificate for the
domain. It doesn't assert anything about the ownership of the domain. So the certificate
will make a claim about the ownership. So even a domain validation certificate, it'll have
a common name and an organization associated with it. It's important to understand that
this doesn't validate that, that is, a domain validation cert is really, it's just saying - it's
like the minimum required to establish an SSL/TLS connection to a remote website.
The next level up fixes, sort of at the weakest level, the fact that the domain validation
isn't really making an assertion about the organization. That type of certificate is called
an OV, an organization validation. The problem is that there's no visible indication of
which is which. And so one of the things that I do wish we had, and I don't know how we
could get it in practical terms, is three levels of indication in the web browser where we
currently only have two. We currently have either EV, which is the Cadillac, the Extended
Validation certificate, or not EV. And in the grouping of not EV is both DV and OV. That
is, essentially nothing but the validation of the domain name and really not the
organization, or the organization validation, which would be nice to somehow be able to
assert because that requires - that's not what this system does.
The whole Let's Encrypt thing is automated, and it is free specifically because it can be,
because you're able to cryptographically validate the domain control with full automation.
You cannot validate organization, that there's a corporate entity, without involving
people. And so that won't and can't be free. That's what you need the CA for. Or, going
further, if you want Extended Validation and an indication in the URL, the green
coloration or glow or whatever it is, depending upon what browser you're using, then that
takes extra work. Okay.
So we need to understand that all this is is that weakest form of validation. And CAs are
probably going to lose that business to the degree and as this takes hold. And, frankly,
that's a big business because Extended Validation certs are still the minority. But this is
sort of inevitable because they actually weren't doing much to get any money for just
doing a domain validation. I mean, so little, in fact, that it could be completely
automated with the so-called ACME protocol, A-C-M-E...
Leo: That's it. That's the name I was looking - that's the funny name.
Steve: Yes, Automated Certificate something. Oh, Certificate Management Environment.
So you could tell that the acronym came first, and they had to reverse-engineer...
Leo: They call those retronyms, yeah, yeah.
Steve: Retronyms, yeah. It's like, okay. We know what you meant. So, okay. So how
does this work? There is an agent, some software which will be written by some pro Let's
Encrypt people for the various platforms. I'm sure that Linux will have the first one. And
the example on the EFF site and their video is of a Linux install where basically two
command lines act to get something, to get the package from the repository, and then
install. And this thing runs.
The idea is that it contains the knowledge of how to configure the server if it had a
certificate. It has the knowledge of how to ask the OpenSSL crypto library to generate a
certificate. You have to ask, there's an interactive session where you tell it a few things,
like what domain name you want and your organization name and the other things that
certs typically have, you know, like geographic location and so forth. Then it has the
ability to query the Let's Encrypt CA.
So part of this service is a new certificate authority that will only be issuing, probably,
domain validation certs through this automated protocol. Oh, and it has to be
preconfigured with the URL of the CA. So that would be bound into this package. And of
course the domain name of whatever it is wouldn't be changing often. So that's not a
problem. So it generates a Certificate Signing Request, a CSR, which is the normal
process we all go through when we're creating a certificate. And that certificate signing
request involves the generation of a public key pair. The server holds onto the private
key. That's its crown jewels. It never lets that go. But the public key is part of the
certificate signing request, which it then is, when appropriate, it sends it to the Let's
Encrypt CA.
But first what happens is it needs to prove that it has valid control of the domain that it
wants to get the certificate which it has just created that it needs to get signed. That is,
we don't want some random person generating a certificate for GRC.com and submitting
it through this automated protocol to have it signed because then they would have a cert
for GRC.com. I don't want them to have that. They would still have to jump through
some hoops to use it because GRC's IP is in DNS, and so people looking for GRC.com
come to my IP, not this bogus entity's IP. So more needs to be done, but still we know
we don't want them to get a cert for that.
So the protocol has three main purposes. One is to validate that you have control of the
domain you are wanting activity for. And that activity would be issuing certificates and
revoking certificates and renewing certificates, you know, fundamental certificate
operations. So there are two ways that you can prove, through this automated protocol,
through the ACME protocol, that you prove you have control of the domain. The first is
that you place content which the CA provides on your web server, which is then made
publicly available, and the CA obtains it. So there's a well-defined, simple, JSON-based,
you know, JavaScript Object Notation, JSON-based protocol where the user, the client of
this ACME protocol says I want to work with a new domain name. I want you, CA, to
ultimately issue me a certificate for this domain name. So let's do that.
So the protocol, the ACME protocol at the client side generates another completely
separate public key pair and, again, holds onto the private key and sends the public key
to the certificate authority over the ACME protocol, along with a domain name that it
wants to associate, essentially. So the CA has a public key and a domain name that the
client says it has a right to have certificates issued for. The certificate authority
challenges it then with a session ID and a cryptographic nonce, so that none of this can
be repeated, and a list of challenges, a list of ways it can prove control of the domain.
Currently there are two.
But the protocol is meant to be open and extensible. And in fact it can technically be
used for other things than just managing a domain name, though that's all it's defined
for currently. So this challenge comes back to the client running the ACME protocol. And
the client can choose which of the things it wants to do. One of the things it could want
to do is to accept the challenge to put some content, which is just a bunch of Base64, so
ASCII-encoded random gibberish, on a certain path in terms of the directory path of the
website on the server. The path always begins with ./well-known/acme-challenge/ and
then a path which the CA has provided. And again, that's a hex-encoded bunch of
random stuff. Hex so that it is valid for a path name.
And so the CA says, essentially is saying in this challenge, here's a blob that I want you
to place at this blob location. Let me know when it's there and ready. So in accepting the
challenge, this client establishes, takes the data from the certificate authority, arranges
to have it appear in public on that path at .well-known/acme-challenge/ and then a
gibberish path, and then says, okay, I accept the challenge. I'm ready to go. The CA then
makes a public query at the domain name that they're negotiating over at that well-
known/acme-challenge/gibberish page and then obtains what's there, which should be
the random gibberish that it gave the client.
And so in completing that loop, involving looking up the domain name, getting the IP
address, making a query, essentially what that tells it is, with provable security, that the
entity that the CA is in communication with is able to affect and influence web pages at
that domain. So it has control of the domain. And so in my example of some bad guy
trying to get a certificate issued for GRC.com, they'd have no way of influencing my
server, of arranging to get a page to appear on a whim on a certain location down my
own public server space.
So what the successful accomplishment does is to bind the public key, which was
generated just for this, to the domain name at the CA. So that, once done, establishes
that the entity has control of the domain. Subsequently, things like issuing certificates for
that domain require that they be signed by the matching private key, which never leaves
the client. And all subsequent operations are signed with the private key that matches
the public key which has been bound to this domain name forevermore.
One of the cool things that the system does at that point, once there is an association
that's been made at the CA, is it ups the ante for all future attempts to make a binding to
that domain name, which is, when I read that in the spec, it's like, oh, nicely done.
Because that's what you want. The idea is the first person to use this Let's Encrypt
system to issue a certificate establishes this relationship. And in doing so, nobody else
can establish a relationship for that domain name without being able to prove they're the
same entity that originally did it. So that's another application for the matching private
key.
But then there's also something known as a recovery code, which the CA sends back as
part of this initial binding protocol, which should be, can be stored separately. The idea is
to - and it's actually very much like SQRL's rescue code. It's offline, and it's a "get out of
jail free" card if you screw something up, if your hard drive crashes, if you lose all of your
cryptographic stuff. If the worst happens, how can you - and because we've upped the
ante on making these associations, how do you say no, no, no, it's really me? Please, I
need you to issue me a replacement certificate because I've lost mine, but it really is me.
Well, this recovery code is, again, long and random. And only the person who originally
made that association would be able to do it. And what's cool is all the recovery code
does is forgive the binding. That is, essentially it says, okay, you still are going to have to
reprove again that you still have control over the domain the way you originally proved
it, but we're going to let you do that. So very nice aspect of the protocol.
And one other very neat thing that I saw there was when you vet - so the next aspect is
you then issue a certificate. So the client takes the certificate signing request that it
made. And it negotiates a transaction with the CA saying, okay, I've got a CSR,
Certificate Signing Request. I need you to sign it. And it signs that request with its
private key, which it uses for proving that it is the rightful requester for activities in this
domain, sends that to the CA. The CA looks through the various fields in the certificate to
make sure that they're all valid. For example, it would be possible for you to request
things that you shouldn't request, like the right to sign other certificates. It's like, oh, no,
no, no, can't do that. So it'll strip out things that you're not able to do. And then, when
everything looks right, it will sign that and return the certificate to the client as part of
this negotiated transaction.
One of the other things it returns, which is what I was going to say I thought was
another really nice aspect of this, is a URL of a simple GET query which the server, the
client running in the user's server, can use to get a renewed certificate any time it wants.
The idea would be it would still have to fit within whatever time horizon constraints the
overall certificate has. But, for example, you could use this to issue short-life certificates.
If you wanted to experiment, for example, with a protocol that we've discussed before,
where instead of a long-life certificate with the need to revoke, you instead arrange to
issue short-life certificates and don't worry about revoking them because they're going to
expire in a couple days.
So the system is a platform for experimenting with that. And they've already
incorporated one of the components you would need into the protocol, which is a way for
the server, daily, to simply say give me a certificate, a refresh of my existing certificate.
You can't change any of the parameters. You can't change the keys or features or
anything. But you could say give me a certificate that's good for four days. And that's
done with a simple GET request. And the reply to that GET request is another signed
certificate good for some length of time. And this makes that very simple. So clearly, if
the world is going to be switching to short-lived certificates, we need a clean, simple, fast
way to reliably get them periodically. And this is already built in.
The way I explained of putting content on a page is one of the two currently defined
means of proving you have control of the domain. The other one is a use of SNIs, Server
Name Indication. That's the technology where a single server that supports SNI is able
to, at a single IP, support different hostnames. And SNI is used to disambiguate which
certificate should be returned to the client who is requesting an SSL connection. The idea
there is that you could use this system for non-web-based applications. Clearly the first
application is a web-based application because you need to put a web page up at
somewhere publicly available at a random gibberish page name in order to obtain the
content and verify ownership. But you can use SSL and TLS for non-web things.
And so using server name indication, the client chooses that as a means of proof in the
protocol and creates a self-signed certificate where a random gibberish domain name is
appearing in the certificate, along with the domain that they're asking for control over.
And so they respond to the challenge that way. And then, again, the CA makes a request
at this random gibberish machine name dot domain name dot whatever, and verifies that
it's able to establish a server name indication enhanced TLS connection that way, and
there again proving that the client has control of the domain. And at that point then the
association is established that allows certificates to be issued and revoked and so forth.
So anyway, it's truly elegant. It's simple, won't be difficult to implement. None of this is
hard. The spec is all open. The plan is to bring up a CA that operates this protocol in
second quarter of 2015, so in the late spring, early summertime this should happen. And
I forgot to mention that once the client obtains the signed certificate, since it is then - it
contains sort of the little mini expert system that knows how to configure the various
web servers on the server platform. It does that. It puts the certificate where it's
supposed to go, and the configuration files to bring up HTTPS on the server, and you're
done. So what the user sees is they run this, or install this.
Oh, and I should also mention that clearly it won't be long before this is built in. Why
wouldn't Apache build this into the server, so you don't even have to add an add-on
module? It's like, yeah, once the system exists, just have it there. So you'd have to be
able to get it for installations that wanted to add it. But the idea is that the operator of
the domain either starts this process or loads it and starts it, answers some simple
questions about the domain name they want to secure, their organization and where
they're located and so forth, the standard things that go into the certificate. They press a
button, and then hum a short tune, and then up pops a dialogue saying, okay, you're
now operating a secure server on that domain. Everything else is done for them. And it
can be made transparent because the lowest level of authentication, just asserting that I
have control of this domain, that's all automated. And I just think this thing is 100%
cool. I'll be very surprised if it doesn't take off. I think it's clearly going to.

 

Is it as trouble free in practice as they claim ?

Share this post


Link to post
Share on other sites

No, it's a pain in the ass actually. Especially if you need to make changes to the domains like I just did. Or when they make undocumented changes to the behavior of certbot and it silently fails your renewals and you don't realize it until 2 days before the cert expires. Or any number of other things that seem routine in the linux world.

I'd hate to see how much more of a pain this is with actual paid certs.

Share this post


Link to post
Share on other sites

Tell me what could be less of a PITA. Folks that I know started this effort, and are still on the board. We'll be at the same conference next week. I'm paying $50,000 out of my budget annually. They just sent me a complimentary hoodie! ;)

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Support us on Patreon!

×