FREE wildcard HTTPS certs from Let's Encrypt for every Reg reader*

Let's Encrypt plans to begin offering free wildcard certificates in January 2018, a move likely to make web security easier and a bit less costly for many organizations. Announced in 2014 as an effort to enhance and accelerate online security, the public benefit certificate authority (CA) has been issuing free X.509 (TLS/SSL) …

[Anonymous Coward]

An admirable effort.

One thing to note though: (computer) security is not a product you simply install after which you can consider yourself to be safe. Of course this is saying nothing negative about this effort,none at all: I applaud the initiative. Because it brings things back to basics: too many CA's are basically abusing their positions by overcharging their customers for something completely trivial.

But the reason I post this is because too many people seem to believe the doctrine that "HTTPS = safer than HTTP". Which is utter bullshit. It all depends on usage and context. Sure, when going to a website which asks you to log in then HTTPS is definitely preferred. But what about a website which allows you to fill out your (or 'a') name with a small comment (like a guestbook)? HTTPS wouldn't provide any significant increase of security there, yet such websites will be immediately dubbed "insecure" by plenty of browsers.

The same browsers which would dub a website such as "ihashax.u" (I made this up) perfectly safe as long as they use HTTPS while requesting: "pls request ur hax here! <entry form>" <small letters> "we h4x everything, including u, filling out this form means u constitutor to us h4xing u!" </small letters>

Whats my point? Security isn't a thing you can install or turn on or off. Yet all this HTTPS pushing does is that there will be plenty of people who'd consider any kind of website safe as long as it's using HTTPS. That's not how security works! "That exe file can't have been ransomware, I downloaed it from this secure website and even my browser said it was secure!".

Security starts by not blindly trusting on automated tools, and using that grey blub between your ears to think things through instead. Too much reliance on security tools such as HTTPS can create a massive risk in itself.

</rant>

[Anonymous Coward]

Re: An admirable effort.

Very sucky that none of this seems to work easily on IIS. After all, 49% of websites now run it.

It's a PITA to have to request certs every 90 days, and as far as I know now that Start.com certificates are not trusted, this is the only remaining free option...

[Anonymous Coward]

Re: An admirable effort.

Of course they work fine with IIS.

Its just the tools that suck. Write a better tool, and make sure to cover all the little corner cases that anything in IIS gives you. Not many decent windows tool makers though.

[Mike Pellatt]

Re: An admirable effort.

Certificate expiry every 90 days is exactly the right thing to do to reduce the consequences of key & cert theft/leakage, given the mess that is Certificate Revocation.

It's absolutely not a PITA, especially as the renewal is easily automated.

And as for IIS, it's not rocket science to use DNS verification via an existing Linux client, convert the key & certs to the IIS format and install them, all automatically. You could even do it all under Windows using cygwin.

[Sgt_Oddball]

Re: An admirable effort.

Not always.. had a mail server running lets encrypt certs and the damn thing wouldn't automatically switch certs if the old cert didn't get deleted when the new cert was created (not a general public mail box, it was mainly used for tests and my personal email which i mainly used as a spam catch or job applications).

That being said having a wildcard cert would be massively helpful for test servers/sub domains for smaller businesses/customers and those who don't have a massive (or any) budget spare for purchasing SSL certs and should generally be roundly applauded.

P.S. I'm also aware it's mearly one part of a larger security overview (SQL injection, remote desktop, weak/non-existant SSH cert passwords, default wordpress/drupal/cms of choice etc. etc. anyone?) - but the more tools we have to secure things, the better.

P.P.S - Pint because it's friday and they probably deserve it.

[Hans 1]

Re: An admirable effort.

Very sucky that none of this seems to work easily on IIS. After all, 49% of websites now run it.

More like 8% as I am counting ACTIVE SITES ....

Source: https://news.netcraft.com/archives/2017/06/27/june-2017-web-server-survey.html

Grabs coat with the FreeBSD Corporate Networker's Guide in the pocket

[Anonymous Coward]

Re: An admirable effort.

"More like 8% as I am counting ACTIVE SITES"

Yes it's quite amusing than now that IIS is way ahead by total number of sites suddenly the exact statistic that was quoted for years for Apache isn't OK anymore and you have to cherry pick a more restrictive one....

[bombastic bob]

Re: An admirable effort.

"Very sucky that none of this seems to work easily on IIS. After all, 49% of websites now run it."

49%? seriously? when apache and linux are both FREE and SUPERIOR to anything IIS has (especially with that C-pound and '.Not' garbage).

the free option that _I_ know of is simple: create your own CA cert, and reference it's web site address in the certs you create based on your own personal CA [all done with openssl]. Anyone hits your site, they get a prompt for the CA, which they can choose to load or not [usually comes with a boatload of warnings the first time, but so what]. After that, YOUR root cert is loaded and you're good to go.

or you can pay the "tollbooth", whatever

[Anonymous Coward]

Re: An admirable effort.

"49%? seriously?"

As per Netcraft's June survey, 49% of all websites run IIS.

"then apache and linux are both FREE and SUPERIOR to anything IIS has (especially with that C-pound and '.Not' garbage)."

Are you perhaps a Daily Mirror reader? Headlines for morons tend to have RANDOM CAPS! Linux / Apache are only free if your time has no value and you don't need support. IIS / .Net scales better and is usually faster on the same hardware and has a far better security record over the last decade than a LAMP stack - there are also numerous other advantages - for instance far easier management of multiple servers and high numbers of SSL certificates.

Is C£ some lame nickname for C Sharp ? If so it's really not funny or witty. Again - there are lots of advantages versus say Java.

"comes with a boatload of warnings the first time, but so what"

The purpose of having trusted certificates has obviously escaped you...

[Jamie Jones]

Re: An admirable effort.

IIS / .Net scales better and is usually faster on the same hardware and has a far better security record over the last decade than a LAMP stack

LOL, How did you manage to write those 2 statements without a grin on your face?

Is C£ some lame nickname for C Sharp ? If so it's really not funny or witty.

He didn't write C£.

Maybe you don't know that the hash sign is also known as the "pound" sign.

You should know that it looks virtually the same as the "sharp" sign.

So, I reply condescendingly to your inappropriate condescending reply to Bob!

Again - there are lots of advantages versus say Java.

Strawman. Neither apache (these are not tomcat results) or nginx are written in Java.

[Anonymous Coward]

Re: An admirable effort.

"He didn't write C£."

Well he did but in words.

"Maybe you don't know that the hash sign is also known as the "pound" sign."

Nope. This is a pound sign - £

"Again - there are lots of advantages versus say Java." - "Strawman. Neither apache (these are not tomcat results) or nginx are written in Java."

That comment was referencing the C# aspersions above. Nothing to do with webservers.

[akiller]

Checkout Certify for automated IIS integration

For simple and automated IIS integration checkout Certify - http://github.com/webprofusion/certify

I've been using it on a couple of servers and it's been working great. If you click the 'configure auto renew' button it sets up a scheduled task to automatically renew your certs.

It's a GUI for ACMESharp (https://github.com/ebekker/ACMESharp) which is a bunch of tools for let's encrypt/IIS if you prefer the console way.

[CrazyOldCatMan]

Re: An admirable effort.

It's a PITA to have to request certs every 90 days

Because it's really, really hard to schedule a job to run every week to check for an updated cert and, if one exists, download it and restart web & imap services?

Wow. If only such a scheduling service existed in modern OS's and supported running a script written in a high-level interpreted language.

[Anonymous Coward]

Re: An admirable effort.

It does work with IIS. The process for installing certd on IIS has always been shit though.

https://github.com/Lone-Coder/letsencrypt-win-simple

As usual the .NET / IIS crowd lets itself down blaming the tools.

Also, you don't need LE to install the cert for you, you can generate just the cert and key then import yourself.

[Pirate Dave]

Re: An admirable effort.

I agree, it could be a bit simpler, and there doesn't appear to be an All-In-One tool for this yet with a fancy MSI installer, etc. But after digging around to do this a couple months ago, it breaks down to three steps:

1. Install the Powershell Gallery module from Microsoft (only needed for Powershell v. 4 and earlier)

2. Use Powershell Gallery to install the ACMESharp libraries

3. Download and run LetsEncrypt-Win-Simple (which needs ACMESharp) from Github to actually request and manage the SSL cert.

Just like this guy said, who also happens to be named Dave, but is probably no relation...

https://it.reinhardt.edu/dave/Lets-Encrypt-Windows.htm

[Anonymous Coward]

Re: An admirable effort.

Even in your example HTTPS makes it safer for end users by:

- Ensuring that the JS being run by their browser was actually that sent by the intended server

- Protecting against MITM redirects to an exploit site

- Providing assurance that the content recorded as coming from you actually did (non-repudiation)

- Protecting against SSL stripping on other linked sites

- many many more

When you argue against the benefits of HTTPS, you are most likely going to be wrong.

[Steve Knox]

Re: An admirable effort.

I believe this is what you meant to say:

This is true: "HTTPS = safer than HTTP"

This is NOT true: "HTTPS = safe"

Adding encryption is just one piece of a complex security framework.

PS. Damn you, El Reg! Complaining that you hadn't adopted HTTPS on every article in which you tell people to adopt HTTPS was one of the few pleasures I had left in this world!

[chivo243]

Re: An admirable effort.

Checks under the mantle, no ice, but El Reg is now https? Checks the sky... what was the 7th sign again?

Good Job El Reg!

[Anonymous Coward]

Re: An admirable effort.

Checks under the mantle, no ice, but El Reg is now https? Checks the sky... what was the 7th sign again?

Good Job El Reg!

Fantastic, I'm even more convinced it's incredibly secure after looking at the certificate in my browser, and seeing it's issued by my own company's internal CA. :)

Isn't https handy to make you feel like your every move isn't being spied upon by your employer...

[Vic]

Re: An admirable effort.

I'm even more convinced it's incredibly secure after looking at the certificate in my browser, and seeing it's issued by my own company's internal CA.

This is why my personal server uses an invalid certificate - if I *don't* get a certificate warning, I know I'm being intercepted. that's really useful when I'm on customer site...

Vic.

[Kevin McMurtrie]

Re: An admirable effort.

Since Let's Encrypt does absolutely no Organization Validation, they're a popular tool for fake stores, phishing, and impostor sites. There's no MITM but there's no guarantees about who owns the endpoint. Browsers really need to flag this with a different security icon because it's easy to forget that there should be a title next to the certificate when you're visiting your bank or an online store.

The same could be said for The Reg's cert. It's nothing more than a generic cert from CloudFlare, another popular tool for fake stores, phishing, an impostor sites.

[Marco Fontani]

Re: An admirable effort.

It's nothing more than a generic cert from CloudFlare

Well, not quite "a generic cert"… the certificate contains another couple second-level subdomains in the cert – a "generic wildcard cert" wouldn't be able to secure "m.forums" or "m.search".

Once another CA will make it as frictionless and cost-effective to have the same, I'll reconsider… We already use another wildcard cert on whitepapers, for example – and that's not under cloudflare, it's RapidSSL.

Unfortunately, the above situation means while we probably could also enable HSTS, we'd be doing that using Cloudflare's certs (something I'm neither strongly for or against, but I'd rather those were "our" certs)… and having two different CAs means we can't yet implement HPKP.

I guess once LetsEncrypt starts giving wildcard certs we'd be able to… so long as they offer one cert for all (?:sub)?domains we require ;)

[Robin Bradshaw]

Re: An admirable effort.

Browsers do flag it differently thats what EV certs are for, you get a big green splodge with your companys name in it.

[Colin Tree]

Re: An admirable effort.

who owns the domain ?

the domain registrar is responsible for authenticating ownership.

they check you have control of the server.

It worked well for me, and did the cron job for updating every 90 days.

(another check that you have control of the server)

If I was doing a store handling others credit details I'd do a bit more.

[Marco Fontani]

Re: An admirable effort.

Complaining that you hadn't adopted HTTPS on every article in which you tell people to adopt HTTPS was one of the few pleasures I had left in this world!

The most common complaint du jour is lack of IPv6 support, you can jump right in!

[CrazyOldCatMan]

Re: An admirable effort.

The most common complaint du jour is lack of IPv6 support, you can jump right in!

Speaking as one who tried to implement it on my (very small) home network - IPv6 is a right PITA to do properly.

Especially if you don't understand it very well/at all..

[Jamie Jones]

Re: An admirable effort.

All my servers run native IPv6, and my home router maintains a ipv6 tunnel with he.net, whilst my home lans runs ipv6 natively.

It's no harder than ip4.

[Allonymous Coward]

Re: An admirable effort.

Complaining that you hadn't adopted HTTPS on every article in which you tell people to adopt HTTPS was one of the few pleasures I had left in this world!

It's OK, you're a proud member of the commentariat. Don't let facts get in the way of a good rant if you still feel like one.

[Anonymous Coward]

Re: HTTP has got to go

You typed all that just to be wrong? Wow.

HTTP is acceptable for nothing, not even static pages. In the glorious times we live, your ISP could invisibly insert malversting, or a disreputable nation state could use your unauthenticated javascript to launch a DDOS against github.

And those things already happened, so the threat is real. Encryption + domain only authentication isn't much, but it will become mandatory.

[Kevin McMurtrie]

Re: HTTP has got to go

There really needs to be a certificate for lightweight digital signatures. Almost all of the Internet is public data that is fine for any observer to view. Encryption is slow and unnecessary when usually all you need is simple tamper detection.

The browsing privacy argument is long dead. Google is watching DNS lookups, recording Chrome activity, and offers site owners free monitoring tools in exchange for some web bugs. Got all of that taken care of? Google sells really cheap domain management services too (with very short default DNS TTL to improve stats collection).

[Ben Tasker]

Re: HTTP has got to go

You typed all that just to be wrong? Wow.

HTTP is acceptable for nothing, not even static pages.

Only a sith deals in absolutes.

There are in fact usecases where plain HTTP is acceptable, and in fact entirely unavoidable. Thankfully they're becoming less common, but they do exist.

For example, I have a script/service that checks whether your ISP is intercepting HTTP connections (by, for example, passing them through a transparent proxy), whether they're messing with the data in any way, whether they cache (and if so, have they protected against cache poisoning attacks etc). That absolutely has to happen over port 80, because it's HTTP traffic that they fuck with.

Now, obviously that's a fairly obscure use case, but my point is this: When it comes to IT Security, if you speak in absolutes then you're likely as much of an idiot as you think the guy you're "correcting" is.

HTTPS is too easily brushed off by many people, but you do no-one any favours by being a die-hard about it. Especially when your response seems to not only assume that Port 80 is only ever used by a browser, but completely misreads the apparent intent of the post you were responding to.

Security starts by not blindly trusting on automated tools, and using that grey blub between your ears to think things through instead. Too much reliance on security tools such as HTTPS can create a massive risk in itself.

He's more right than you are ;)

Simply enabling HTTPS isn't enough (though it should be a first step in the absence of a strong case against it), but we've got to break this idea that users have developed that HTTPS means the site is safe. It's a dangerous false sense of security.

All the cert check actually does is verify that the server you're speaking to is authorised to speak for the domain you connected to. It doesn't make hs.bc any more legitimate.

[Anonymous Coward]

Re: An admirable effort.

Anyone who doubts the value of HTTPS should see Troy Hunt's course on Pluralsight - https://www.pluralsight.com/courses/https-every-developer-must-know. In fact, forget the "anyone who doubts..." bit. Everyone should see Troy Hunt's course on Pluralsight (other providers are no doubt available, I have no commercial relationship with either Troy or Pluralsight, etc. etc. blah blah blah)

HTTPS is a necessary component of a secure web. It is not however a sufficient component. So yes, HTTPS == safer, HTTPS != safe

[CrazyOldCatMan]

Re: An admirable effort.

HTTPS is a necessary component of a secure web. It is not however a sufficient component. So yes, HTTPS == safer, HTTPS != safe

Especially when using encryption protocols that were deemed insecure at least 5 years ago.

Easy steps to a (more) secure web:

1. Get SSL cert

2. Switch off old protocols.

3. Don't run Wordpress/Joomla/[sprawling mass of insecure PHP du jour]

[Anonymous Coward]

Re: An admirable effort.

"3. Don't run Wordpress/Joomla/[sprawling mass of insecure PHP du jour]"

Quite right - don't run LAMP stacks if you care about security...

[Adam 1]

Re: An admirable effort.

@ShelLuser,

Now I have a conundrum. Your rant deserves to be upvoted in one part and downvoted in the other.

CAs abusing their positions, reminding of the need to continue using the grey matter in addition to HTTPS, yes, yes, yes again.

But then you go off and claim it is no safer than http. Sorry, but that is amanfrommars crazy talk.

Let's address what you get from HTTPS. Firstly, you get a degree of privacy from MitM observers.* You get a guarantee that the page and resources referred were not changed in transit. You also get a guarantee that data you submit (including identifiable information) is not visible to a MitM. You are right to point out its limits. For example, the certificate on this site stops anyone interfering with the site between here and cloudflare. It doesn't say anything about MitM between cloudflare and el reg. It doesn't mean that El reg has appropriate controls about its staff access to those servers and databases. It doesn't mean they don't sell my data to advertisers. But I don't think HTTPS needs to cure cancer for it to have earned the praise of "an improvement".

It is like arguing that autonomous braking systems are a load of bull because people who have them adopt riskier behaviour.

* I should note here that the DNS lookups and data payload from those domains still allow partial MitM tracking, at least at the ISP or VPN provider level.

[Sir Runcible Spoon]

Re: An admirable effort.

"Sorry, but that is amanfrommars crazy talk."

You just haven't cracked the cypher yet.

[CrazyOldCatMan]

Re: An admirable effort.

"Sorry, but that is amanfrommars crazy talk."

You just haven't cracked the cypher yet.

Even using quantum computing, the time between now and the heat-death[1] of the universe[2] isn't enough to crack *that* cypher.

[1] "Heat is work and work's a curse,

And all the heat in the Universe,

Is gonna cooool down 'cos it can't increase,

Then there'll be no more work and there'll be perfect peace,

Really?

Yeah - that's entropy, man!"

- Flanders and Swann: "First and Second Law"

[2] [Insert end-times solution of choice].

[Sir Runcible Spoon]

Re: An admirable effort.

" the time between now and the heat-death[1] of the universe[2] isn't enough to crack *that* cypher."

Only if you try to brute force it :)

[Huw D]

Re: An admirable effort.

To crack that cypher, first get some crack...

[Jonathan 27]

Re: An admirable effort.

I think you bring up a good point. The majority of people don't understand what a TLS (secure) connection actually secures and just think it's vaguely "safe". I don't know how we could communicate that what it means is that the communications between your browser and the website are encrypted and verified.

Browser manufacturers are doing a really bad job of communicating that right now. Chrome, for example has made it increasingly difficult to check certificates, you can't even get them from the lock icon anymore. They're hidden in the page inspector.

[Wensleydale Cheese]

Re: An admirable effort.

"Chrome, for example has made it increasingly difficult to check certificates, you can't even get them from the lock icon anymore. They're hidden in the page inspector."

aka the "Trust us, we know better than you" model.

[Pomgolian]

Fantastic news

Let me be the first to buy those guys a beer.

https://letsencrypt.org/donate/

[John Crisp]

Handy

Simple bash a script

https://github.com/lukas2511/dehydrated

[Anonymous Coward]

Don't be so ridiculous...

A San Francisco company that really cares.

So you set up a company in a mega expensive environment just to help people be secure without any reward?

Cynical I am, with good reason.

[hazzamon]

Well, they are a registered non-profit organisation.

[Anonymous Coward]

non-tax

[Wensleydale Cheese]

"Well, they are a registered non-profit organisation."

Which doesn't mean that they have to pay themselves rubbish salaries.

[heyrick]

There is a dark evil danger to the big uptake of HTTPS

An increasing number of public WiFi APs (hello KFC Laval, I'm calling you out on this) will push a dodgy certificate if you try to access an SSL page. The less geeky might accept this and fail to realise that the AP, no doubt for shitty copyright infringement reasons, has just dropped a MitM on them and they have immediately compromised all of the security that HTTPS is commonly understood as offering. Log into Amazon? Your bank? Congrats, the AP could be logging it all or passing metadata on somewhere else.

Here's what happened a couple of years ago when I visited Google at the aforementioned KFC. http://i.imgur.com/aXz8A8I.png

Now I use my phone as a personal AP and avoid public hotspots.

[john jones 1]

Re: There is a dark evil danger to the big uptake of HTTPS

EXACTLY - trusting any Certificate Authority means you have to trust all of them (that are installed)

a much better way would be provide an option to use DANE which works by DNS so the domain owner provides the key in a dynamic method (effectively a self signed or CA key depending on the owners pref )

https://tools.ietf.org/html/rfc6698

yes you have to trust the root for that domain e.g. .com but the trust path is very obvious

it is also a nice way to distribute PGP or SSH public keys...

[Anonymous Coward]

Re: There is a dark evil danger to the big uptake of HTTPS

Unfortunately, the browser level fix will be to disable the ability for anyone to accept a cert.

You can already trigger this for your own domains using strict-transport-security. Do it!

[John H Woods]

Re: There is a dark evil danger to the big uptake of HTTPS

I agree... any but your own WiFi is the wild west... The only thing I'll do after login is go to the appropriate (corporate, client or personal) VPN.

Unless you want a huge download or have poor signal, I agree that mobile is the usually the best bet.

Decent mobile data speeds and allowances are widespread (my 12GB/£13/mo is just about perfect for me) and gets at least a few Mb/s in most places, more than enough for most work purposes.

Plus... No need to register a temporary email address; no need to keep signing back in (not to mention the difficulty loading the signsign-in page when your browser wants to HTTPS) and no having to randomize your MAC to limit tracking.

[Jonathan 27]

Re: There is a dark evil danger to the big uptake of HTTPS

I'd recommend not using any public Wi-Fi, they're not secure. A VPN is a minimum, but even then I'd be wary because anyone on the network gets local network access to your device (except in the most expensive Wi-Fi devices, which they're probably not using).

[Anonymous Coward]

Re: There is a dark evil danger to the big uptake of HTTPS

Wireless Client Separation/Isolation is a basic feature on pretty much every AP on the planet, even the nasty TP-Link ones so I think it's a bit unfair to say they get local network access to your device.

[TheVogon]

Re: There is a dark evil danger to the big uptake of HTTPS

"Wireless Client Separation/Isolation is a basic feature on pretty much every AP on the planet, even the nasty TP-Link ones so I think it's a bit unfair to say they get local network access to your device."

You need to read: https://en.wikipedia.org/wiki/Promiscuous_mode

[Jamie Jones]

Re: There is a dark evil danger to the big uptake of HTTPS

You need to read: https://en.wikipedia.org/wiki/Promiscuous_mode

LOL, no, it seems you do.

Hint: These are not ad-hoc networks.

Hint2: Each client has a unique encryption key to the AP.

Hint3: The only way a client can see data is if the AP specifically sends it to the client.

[TheVogon]

Re: There is a dark evil danger to the big uptake of HTTPS

"LOL, no, it seems you do.

Nope, read and learn.

"Hint2: Each client has a unique encryption key to the AP.

Hint3: The only way a client can see data is if the AP specifically sends it to the client."

Not the only way. FYI, ARP traffic still gets broadcast across the network using a shared key so that DHCP can maintain clients.

So, If the ARP table is poisoned with a broadcast MAC on the client entry you will force the clients system to use the broadcast shared key when sending data. If the system is fooled into using the shared key to send data it can now be seen and you will bypass the client isolation.

Thus, if you set your local static ARP entry using the clients ip with a broadcast mac your local system will think its sending broadcast traffic when talking to that client and use the shared key allowing the client to see your traffic...

[Anonymous Coward]

Re: There is a dark evil danger to the big uptake of HTTPS

I still don't see anything about someone being able to gain direct access to my machine over a WLAN? If client separation is turned on, traffic will not be passed through the access point to separate wireless clients.

[Kiwi]

Re: There is a dark evil danger to the big uptake of HTTPS

Now I use my phone as a personal AP and avoid public hotspots.

I'm using OpenVPN (well, playing with it anyway) with a cert-based connection (certificate created on the server then copied to the device). So far seems to be working well but with one browser (IIRC opera mini) it wasn't doing all the DNS etc like it was supposed to, that still went through other things (opera and (surprisingly) chrome.

Hopefully can find more soon to say whether this is something I can trust with banking app etc or not, don't suppose anyone here at El Reg has more enlightenment than I can find thus far?

[Ben Tasker]

Re: There is a dark evil danger to the big uptake of HTTPS

Hopefully can find more soon to say whether this is something I can trust with banking app etc or not, don't suppose anyone here at El Reg has more enlightenment than I can find thus far?

Has generally worked well enough for me. It was a while ago I set it up, but this is the setup I went with https://www.bentasker.co.uk/documentation/mobile-phones/277-android-protecting-your-network-data-from-local-snooping

I've not had any issues using banking (though I only do it in browser, as I'm not too comfortable with the state of banking apps (though they may have improved in the meantime).

That's assuming, of course, that you control the VPN server, and trust (to a given extent) the hosting provider. You also need to think about what type of server you're using, if it's an OpenVZ slice (for example) there's slightly more risk of someone in another slice on that server being able to jump slices. Probably still lower risk than random public wifi APs though.

The DNS misbehaviour you saw with Opera mini, was it just that you didn't see the queries transit the tunnel? IIRC it forwards all requests (including the initial DNS lookups) via one of Opera's servers, and hopefully that connection was going via the VPN?

[Kiwi]

Re: There is a dark evil danger to the big uptake of HTTPS

Hopefully can find more soon to say whether this is something I can trust with banking app etc or not, don't suppose anyone here at El Reg has more enlightenment than I can find thus far?

Has generally worked well enough for me. It was a while ago I set it up, but this is the setup I went with https://www.bentasker.co.uk/documentation/mobile-phones/277-android-protecting-your-network-data-from-local-snooping

Thanks, looking now (well soon, when I locate a circular tuit! :-) )

That's assuming, of course, that you control the VPN server, and trust (to a given extent) the hosting provider

I control the server; runs on a mate's machine that does a couple of other jobs for him. I can understand concerns with hosting providers.

The DNS misbehaviour you saw with Opera mini, was it just that you didn't see the queries transit the tunnel? IIRC it forwards all requests (including the initial DNS lookups) via one of Opera's servers, and hopefully that connection was going via the VPN?

Afraid I can't recall atm. I checked with ip-check.info or a simillar site and my real ip was showing. I think it was something else that made me look closer, maybe a sub-domain on the local net that wasn't resolving. Coukd be the issue you mention but my local ip leaked on android. Setting the client up on a linux box seems fine, as far as I can tell nothing leaks.

But I will read the article you linked in due course, and thanks for the time even if I don't use it. Would link the article I used but my main machine is still dead :-(

[JakeMS]

Not just for HTTPS

Let's Encrypt is super handy, specially when paired with the acme.sh script which can automatically renew a cert using your DNS providers API. In addition, it doesn't require python to be installed on systems where it otherwise would not need to be.

Also, Let's Encrypt is not just for HTTPS, you can use the certs for basically anything - I use them for a mail server, an EPOS system (encrypted stunnel from EPOS to Database server for product sync/update) and of course, websites.

At the end of the day they are just regular certs.

As for wildcards, great idea. But I'm not sure if I will be using them as most of our subdomains are split across multiple machines.

[Anonymous Coward]

They already hard fail when CAA doesn't list them - of course this requires people to use/support CAA in the first case....

[thijs]

They already do and will reject a request if the domain has a CAA record that does not list LetsEncrypt.

[Anonymous Coward]

Let's Encrypt improve secrecy, not security

There's a big misconception: the way Let's Encrypt works, it just improve transmission secrecy, not security. Badly configured and vulnerable web servers can be still be p0wned, and malicious content served.

From a security perspective, it could also make IDS/IPS inspection harder, without proxying HTTPS.

[sitta_europea]

Re: Let's Encrypt improve secrecy, not security

Yeah, there's a lot of muddy thinking about security, and securing the transport between server and client very likely doesn't do what the client user thinks it does. Which seems kinda counter-productive.

[Anonymous Coward]

Let me see if I get this right.

So it's now easier than ever to get a "trusted" digital certificate for your website - simply register a domain, and prove that you own it.

Given that the level of trust of a site for your typical user is based on a green or red icon/text indicated by the browser (no idea about degree of vetting in OV, EV and DV) doesn't this mean that the assurance level (or trustworthiness) of any HTTPS web site has just dropped a notch?

[Ben Tasker]

doesn't this mean that the assurance level (or trustworthiness) of any HTTPS web site has just dropped a notch?

Not really. For DV level certs, you still just needed to exercise proof of control over the Domain (depending on the CA, that might be clicking a link in an email, creating a DNS record, or creating a specific page on the site).

So it's no harder to provide the proof for a cert. The only thing that's gone is the payment trail (but then, if you were that way inclined, you'd use stolen details anyway. Cert might get revoked eventually, but Chrome doesn't check CRLs and it'd take long enough for you to catch a few people out anyway).

So the assurance level hasn't really changed. What might be changing though (hopefully) is people's understanding of just what level of trust having a DV certificate actually implies (very little other than that you appear to have connected to the correct server)

[Anonymous Coward]

Oh, I wish it was just as simple as that

There (as ususal for Linux/FOSS) are seemingly incompaible guides on how to add a HTTPS certificate and enable HTTPS on a basic Linux web server running Apache.

Why can't things be made simple then more people will take up the offer?

I spent at least 5 hours trying and failing to get HTTPS working properly on a simple site. The site serves as a blog where a few short stories of mine are published. No money/e-commerce yet the browsers are starting to complain that the site is insecure when logging in. Do I really need HTTPS? Probably not but... it won't be long before non HTTPS sites are automatically blacklisted.

How long before the Pub opens and I can watch the cricket with a nice pint of 6X in the hand.

That's what summer is all about. Not faffing around trying to get HTTPS to work.

[Marco Fontani]

Re: Oh, I wish it was just as simple as that

yet the browsers are starting to complain that the site is insecure when logging in. Do I really need HTTPS?

Do you value giving all eavesdroppers on the connection between your computer and your server (both included) the ability to log into that site as yourself and do as they please with it?

… because that's effectively what's happening when you're logging in over HTTP.

It's even worse if you used a password you've re-used elsewhere… as now they also have access to that other thing. Or, worse, things.

Use https, use a password manager and create long, secure passwords… and don't use a password on more than one site.

[cbars]

Re: Oh, I wish it was just as simple as that

#1) Get certs (either generate your own CSR or use default LetsEncrypt cert)

#2) modify the apache configuration files and your server hosts file: add hostname (example.com) to /etc/hosts and /etc/apache2/sites-available/default-ssl

#3) Put your certs in the right place (according to your Apache config, but really makes sense to put them with the rest of them

(sudo) cp mypubliccertificate.crt /etc/ssl/certs;

(sudo) cp myprivatekey.pem /etc/ssl/private;

#4) Make some changes to your server to lock it down, in apache conf:

SSLProtocol -All +TLSv1.2

SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA

SSLCompression off

#in default-SSL:

add ServerName

point to new certs in /etc/ssl (SSLCertificateFile and SSLCertificateKeyFile )

If you get stuck anywhere, RTFM: http://httpd.apache.org/docs/2.4/ssl/

Things are not that simple because we're talking about obfuscating messages using large prime numbers so somewhere someone needs to put the effort in. If you don't want to do it yourself, pay for hosting and tick the box that says HTTPS :)

[DropBear]

*Encounters the expression "changing the narrative" in the article* *scrolls back to the top* *confirms author is from the US*...

[alain williams]

What is the GCHQ/NSA take on this ?

Given the ongoing set of wikileaks revelations I would be surprised if they did not have a means of subverting Let's Encrypt.

[Anonymous Coward]

Re: What is the GCHQ/NSA take on this ?

I wouldn't be totally amazed to hear that they organised and funded the project. They could claim to be making people safer with a straight face, so it'd look good on the budget; and they'd be in a perfect position to MITM whoever they felt like.

[Richard Lloyd]

Multiple servers?

Let's Encrypt wildcard certs are probably tenable if you're going to use them on only one server. If you have more than one server, I suspect you'd have to nominate one server as the wildcard renewal server and then after a renewal, have it copy the new cert files to your other servers that need it (assuming that's allowed in Let's Encrypt T&C's - paid wildcard certs sometimes insist on you paying per server!).

You can pick up paid wildcard certs for about 70 quid a year nowadays, which isn't too bad if you're planning 10+ subdomains on them. One obvious trick is to buy a 3 years wildcard cert so you don't have to renew/re-install the certs on multiple servers too often.

[Jonathan 27]

Re: Multiple servers?

You'd have to write your own script/application to distribute the certs. I don't think there is an available OSS solution. Let's Encrypt is targeting personal and small business sites that don't care to pay for a more-expensive cert provider, so I'd guess that anyone with multiple servers can probably afford to pay GoDaddy, Verisign or whoever.

I personally use Let's Encrypt on my personal sites, which are run off one Amazon EC2 instance. But for work we use the more expensive certs and will continue to. What's $100/year if the company makes millions?

[Ben Tasker]

Re: Multiple servers?

Let's Encrypt wildcard certs are probably tenable if you're going to use them on only one server. If you have more than one server, I suspect you'd have to nominate one server as the wildcard renewal server and then after a renewal, have it copy the new cert files to your other servers that need it

More or less what I do. Certbot writes the cert out into a git repo, and my wrapper script commits and pushes. Other machines on my edge poll periodically to see if the repo has new commits, if it does, git pull and then reload nginx.

One obvious trick is to buy a 3 years wildcard cert so you don't have to renew/re-install the certs on multiple servers too often.

As of CAB Forum Ballet 193, the maximum validity of a certificate is being capped again. So from next year (March IIRC), the maximum length of a cert will be 825 days (basically 2 years with a little padding to allow for renewal times).

There was a previous attempt to bring the lifetime down to 13 months, but it didn't pass. All the same, expect that 2 years to drop further at some point in the future (especially as it's Google who wanted 13 months, so changes may come via Chrome rather than a ballot).

[JeffyPoooh]

Certificates + BlockChain technology = Authorityless Certificates

Dispense with centralized 'Authorities'.

[Jonathan 27]

Re: Certificates + BlockChain technology = Authorityless Certificates

How do we deal with the constantly increasing performance cost?

[User McUser]

I disagree

"Before Let's Encrypt, HTTPS was difficult and cost money," [Josh Aas] said.

Getting and installing an SSL certificate wasn't ever difficult - it was actually quite straight-froward and easy if you just RTFM and followed the instructions. And it only cost money if you wanted a certificate that was signed by someone other than yourself.

[Mr Tumnus]

Oh! Interesting ...

"Let's Encrypt certs must be renewed every 90 days..."

Ah. No longer interesting ...

[Steven Raith]

....because a script to run 'certbot renew' once a day (it won't do anything unless the cert is due for renewal, whereupon it'll automatically overwrite the old one) and telling your webserver to look for it's SSL cert wherever you made Certbot dump it is just far too much work for a competent sysadmin.

Steven R

[Anonymous Coward]

If you're replacing WILDCARD CERTS automatically on your servers, using scripts, every 90 days, you're doing security wrong. If you have a wildcard cert provider who is handing them out to a script, you're doing security wrong. If you automate the security of any prefix before your domain name (ftp.company.com dc.company.com www.company.com fileserver.company.com), every 90 days, in this way, you're doing security wrong.

But you crack on, thinking you're a competent sysadmin, because you managed to run a script on a server, that does something that's crackpot stupid.

[Anonymous Coward]

"If you're replacing WILDCARD CERTS automatically on your servers, using scripts, every 90 days, you're doing security wrong."

Yes of course, no one can write automated systems that function securely. Why, all those top security firms that have automated systems to update their certificates on a regular basis or as needed are doing it wrong, they really need someone to do it all for them!

"But you crack on, thinking you're a competent sysadmin,"

Perhaps you're not as competent as you imagine yourself to be?

[SImon Hobson]

Please stop repeating the lie that there is no cost in using SSL.

If you use shared hosting, you cannot use your own cert - and must pay your hosting company to add a cert. A provider we use at work charges £50/site/year ! I get "free" hosting with my internet service, but this does not support SSL at all - so yes "all I have to do" is switch hosting which means paying someone else for something that is currently included in my internet package.

If you host more than one site, then you have to use SNI - which puts restrictions on the software you can use and also locks out older clients. Whether you like it or not, older clients are still in use - whether you piss off the users or not is up to you.

So yes, it's now really cheap - but it is not "free" in general.

[Kiwi]

Please stop repeating the lie that there is no cost in using SSL.

If you use shared hosting, you cannot use your own cert - and must pay your hosting company to add a cert. A provider we use at work charges £50/site/year ! I get "free" hosting with my internet service, but this does not support SSL at all - so yes "all I have to do" is switch hosting which means paying someone else for something that is currently included in my internet package.

If you host more than one site, then you have to use SNI - which puts restrictions on the software you can use and also locks out older clients. Whether you like it or not, older clients are still in use - whether you piss off the users or not is up to you.

So yes, it's now really cheap - but it is not "free" in general.

Mebbe you need to look at the subject a bit more in depth? Hosting - get your self a Pi or other small machine (depending on what you're doing), chuck Apache or Nginx or some other secure server software on it, install whatever you need for PHP/SQL etc. There's not much involved in that.

LetsEncrypt's certbot does the job of configuring your sites for HTTPS, so no effort there (seriously, NO EFFORT REQUIRED just run the bloody script!)

As to multiple sites, I've a few subdomains on 2 machines on one IP (one email/web/cloud storage, one runs a second cloud storage instance (different port) and also the VPN I'm playing with - first is a Toshiba M200), have no problems with certs or anything. Yes the certs are multi-domain but there's no issue there so far as I have tested (which is with modern browsers, willing to try stuff older if someone asks and I get round to reading said response).

It really is a trivial process to get it running, and you can do your own hosting (if your ISP doesn't allow that, and you live outside the US, then get another ISP!)

[SImon Hobson]

Mebbe you need to look at the subject a bit more in depth?

Mebbe you need to read what people write.

No-where did I state that these were insurmountable problems.

I could host a site locally (I already do for one, and that's SSL enabled) - but that has it's own costs. Or I could pay to host the site with another host that does support SSL certs - but that has a cost, paying for the hosting that's currently 'free', and paying whatever the host charges for adding an SSL cert (some do it free, some charge £50/year !).

The point is that it's not a zero cost for many situations. And it's annoying to read time and time again this assumption that every site currently not SSL enabled can be enabled by simply getting a zero cost cert.

[Ben Tasker]

If you use shared hosting, you cannot use your own cert - and must pay your hosting company to add a cert.

Actually, a good number of hosting providers have been enabling LetsEncrypt support in CPanel (or whatever interface they expose to customers), so whilst this is true for some, it's no longer a hard and fast rule.

I get "free" hosting with my internet service, but this does not support SSL at all - so yes "all I have to do" is switch hosting which means paying someone else for something that is currently included in my internet package.

To be fair, that's not so much a cost in SSL as a limitation in the hosting you're using

If you host more than one site, then you have to use SNI - which puts restrictions on the software you can use and also locks out older clients.

There're very few restrictions on the server side software nowadays, because most things now support SNI. The number of distinct older clients that don't support SNI in the wild is also now quite low (though, as you note, still with a *lot* of users behind them)

So yes, it's now really cheap - but it is not "free" in general.

It is (or can be) entirely free in the fiscal sense. You can get a cert for £0.00 (and have been able to for a long time).

But, you're right in that there are associated costs - additional processing overhead (however small, it's still there), the need to balance pissing off users with old software vs maintaining security.

But, on the other hand, if you're on cheap (or free) shared hosting, you probably don't have the user volume to have to worry too much about pissing the users off, and the additional processing overhead is your hosts problem.