Web body mulls halving HTTPS cert lifetimes. That screaming in the distance is HTTPS cert sellers fearing orgs will bail for Let's Encrypt

Re: Follow the money

Show me a company that actually revokes certs when they're supposed to and I'll buy your argument.

PCI-DSS requires revocation every time someone who had access to the private key leaves or even changes roles. I've seen only one place where that happened in my entire career.

Shorter lifespan is better. Three months should be the limit (same as passwords under PCI-DSS).

For all those who complain, it's 2019. Automate already.

I'm quite troubled by the emerging themes here: too much work and not worth the trouble.

I'm a network/app delivery engineer at a company that runs tens of thousands of servers/instances/containers/network boxes etc. I've been a developer for years, and after that a hosting engineer.

To cut to the chase: the core question is whether adequate security is a requirement, and if so, what constitutes adequate security.

I realize that it can be a lot of work, but that shouldn't be the main criterion. And, I dare say, at many companies it's more work than it should be simply because of poor design, architecture, and standards.

And lack of executive support for it.

I'll step off my soap box now before I fall off and get hurt.

Re: Certificate transparency/logging and CAA DNS records better than shortening cert lifespans?

Or just allow the site to host the public key in their DNS...

DNSSEC validation of the key required for SSL transactions with the same organisation...

Re: Certificate transparency/logging and CAA DNS records better than shortening cert lifespans?

Because your gran is going to love and understand that checklist and make an informed choice. Oh yes.

Re: Certificate transparency/logging and CAA DNS records better than shortening cert lifespans?

How is this any more effective than a CA? It seems like the observatory has exactly the same trust issues a CA does, you're just shifting who happens to be doing the computations to create the cert.

Re: False sense of security

I'm only vulnerable to criminals with falconry skills,

and also cats... That's not criminals with cats, you understand, just cats...

Re: False sense of security

and air-rifles

Re: False sense of security

I'm only vulnerable to criminals with falconry skills...

Or shotguns, or falcons of the opposite sex (well, it might delay them at least), or eagles (there's always someone bigger/faster/stronger), or Wind Turbines (splat), or air ones (jet engines/planes) for that matter, although in the latter case there probably won't be anything left to extract the CC from, so I guess you could call that safe ;)

Re: I still wait for Let's Authenticate...

In the sense that you know you are talking to the owner of that cert it will always be safer.

In terms of knowing who own that cert, you are right... But that's where publishing the public key by another mechanism (And Let's Authenticate seems a good enough name to me) comes in.

HTTP - you don't know who you are talking to.

Re: I still wait for Let's Authenticate...

The other half is authentication

In a sense, the only half is authentication - if you can't authenticate, the encryption is useless because you may simply be talking to a MITM or other ne'er-do-well. Unfortunately, certificates are always going to be dumbed down because the trust model requires a manageably-small number of root certificates to be pre-loaded in web browsers and that essentiallly means that either those root authorities are directly issuing certificates to millions of unverifiable entities in far-flung countries or that they're authorising a long chain of unverifiable intermediaries which might or might not end with someone who is sufficiently close to the applicant to be able to verify their legitimacy.

The price and/or lifetime of the certificates has no bearing on any of this.

As in so many aspects of computer security, the mathematical proof of correctness depends on a premise that cannot easily be delivered in the real world.

Re: Money spinner

Same's true of most commercial certs; heck, they don't even have to be set to auto-renew for you to get a substantial amount of time (up to two years) to use the cert for whatever you like. When it expires, as long as you can cut them a check you can probably keep going.

Re: Money spinner

Short answer: not at all.

Long answer: Not at all, as this is exactly the situation shortened lifetimes is trying to prevent. Well, your first point is. Your second point about a domain having expired isn't at issue, because you are then perfectly within your rights to buy it and get a cert for it, whether your purposes are malicious or not. There's nothing anyone can do about that.

But back to your first point. Let's postulate two servers, Alice and Bob. Both host an HTTPS server with a certificate. Alice has set hers up using LetsEncrypt or someone else with a 90-day expire time. Bob has set his up with a 39-month cert back when they were still in use. Today, you break into both of them and steal their certificate files. You're planning to impersonate these servers on a compromised connection to get users to trust your fake sites. Having stolen the private keys, there's little you can't do. That's why private keys are protected. But you can only impersonate Alice for at most ninety days unless you can break in again. If Alice improves her security, or if you obtained the file by paying for an attacker to obtain the file for you, it could be much more difficult to get a new one. You couldn't use that cert to renew itself; only the real server can do that because LetsEncrypt uses a DNS check. Meanwhile, you can impersonate Bob for quite a long time. His cert is valid for a little over three years. That gives you a lot more time. If neither fix their security, you have access to impersonate them for as long as it takes them to figure it out. If they do fix their security, Alice is safe much earlier than Bob is, unless they realize that the certs have been compromised, in which case they both revoke them and we're back to the same again.

Re: Shakedown time

"I ..... would happily expire my certs daily if it improved client safety."

This is not a good general solution for all certs.

What that would do would be to make systems much more fragile.

If, for any reason, you can't renew, then stuff starts falling over. In some cases, it's a web site, in some cases it's infrastructure gear.

Also, this makes the idea of a MITM attack on cert renewals both more appealing and more practical.

Re: Shakedown time

Browsers implicitly trust HUNDREDS of CAs. If you think that green padlock is an assurance of anything but a site's ability to pass some cursory checks then you're sadly mistaken.

Re: IoT

Just waiting for Dan Tentler to hear about that one -

Start a building on fire over the internet? Challenge accepted!

Re: IoT

Look, kid. In my day we had to use wood-burning computers, but we made do.

Re: Won't somebody think of the meetings ?!

Many organisations won't let you automate expense payments like that, there'd have to be some human in the loop to approve and accept the charge before the certificate could be renewed.

Painful I know, but f'king bean counters, it costs more to implement their accountability requirements than the benefits accrued from them.

Re: DV's only

Why can't this be done with a public key attached to the domain record in the DNS, signed by a trusted entity (such as whoever runs the TLD of that particular domain name?)

Re: DV's only

"The *only* thing that an SSL/TLS certificate assures you is that when you make a connection to xyz.com, you you are exchanging data with someone who controls the domain xyz.com - that is, the connection is not subject to DNS spoofing or active man-in-the-middle attack."

Unfortunately it doesn't even do that in any meaningful sense, because with the possible exception of state actors and perhaps tier 1 backbone providers, no attacker is going to bother with MITM any more. It's so much easier to exploit broken or misconfigured software at the endpoint, which obviates transport security entirely. Once the endpoint software (or OS) is compromised, nothing stops the attackers from viewing all the data being received there, in the clear. So yeah, you're communicating with xyz.com, all right... and also nefarious.ru, who are siphoning it right out the back, but TLS can't tell you that.

And of course the even more common failure to secure data at rest, which has nothing to do with communication at all. Fake sites still crop up from time to time and steal data from a few of the very most unwary, who ignore the warnings TLS provides them anyway. But these are not the preferred attack vectors any longer, if indeed they ever were. Attacking the endpoint is both far easier and much more lucrative, since you can target exactly what you want and get all the users/customers at once (and often persistently, too) without the immense volume of chaff or finicky per-connection setup hassle.

Re: DV's only

EV certs are dead, since Chrome and Safari stopped displaying them, because users ignored them

Possibly overly optimistic. While browser manufacturers scorn EV certs, the CA/BF loves them. Their Code Signing Working Group mandated EV certs for code signing (as if that wouldn't be a fucking nightmare) in their draft spec, and - as some may remember - Microsoft briefly adopted that position, before backing down in the face of ISVs waving torches and pitchforks. It wouldn't surprise me if the CA/BF keeps pushing EV certificates for years to come, even with the browsers ignoring the distinction. And they'll try to wedge them into more non-TLS applications.

I agree that EV certificates are largely pointless - the additional cost doesn't buy much, considering that CAs have a record of not performing the additional verification properly (or at all, in some cases), and the HSM requirement for key management is not universally enforced and was poorly written in the first place. (FIPS 140-2 L2 security on the HSM isn't worth a damn, and prevents people from using inexpensive hardware with open-source drivers.) But CAs and the CA/BF will try to find ways to keep the EV cash cow alive for a while yet.

Re: An issue of Google's own making ...

> I *can* teach my mother to avoid a website that Chrome (other browsers are available) labels as "INSECURE".

I think what you mean is, "I can teach my mother to avoid entering her banking details into a site which Chrome etc labels as 'INSECURE'". Even that minor toe-hold goes away when all sites are HTTPS. But it never really helped in the first place.

The theft of sensitive data by packet-sniffing of unencrypted traffic is only a tiny part of the problem. The main problem is entering data into fake sites which look legitimate. If the web site looks like her bank's website, your mother will use it. It may even proxy to the real site behind the scenes.

Anyone can register a plausible-looking domain like "halifax-online-services.com" - and could also register a similar-sounding company name if they want an EV cert (but why bother, since 99% of users ignore them anyway?) I expect most users would enter their login details at "halifax-secure-banking.dyndns.org" if the content looked right.

"Secure" (in the weak sense provided by HTTPS) is very different to "trustworthy".

Re: An issue of Google's own making ...

"Nearly all the blogs I visit have comment sections."

They may have but very few have valid comments added to them. When I had anonymous comments enabled it was a full time job deleting the spam, even with spam filters in place. Requiring register to comment was almost as bad, every day one would get 50-100 signups (usually using gmail), which stopforumspam detected as coming from known spam and malware sources. Leave it for a few days and one had 1000s of bogus users and a similar number that were suspect.

Re: An issue of Google's own making ...

Actually, it does help security because it prevents a malware injection in the transport (a la Chinese Cannon). The world of the Internet today pretty much necessitates 100% encrypted transport because you can't be sure ANY unencrypted transport won't be usurped and turned into an attack vector.

Wherever we can, yes, obviously, but as mentioned above, for EV certs and some other types it's still a manual (and long drawn out) process.

Re: Encourages automation, increases security, reduces costs

Everything's possible. However, LE is run by some pretty charitable people with a track record of not being that rent-seeking. In addition, all their code is open and freely-licensed, so someone could copy their system quickly. Of course there'd be some difficulty getting the new system trusted by everybody, but it could eventually happen. I think we'll probably be fine.

Re: One nasty habit Google employees have

>you can set up your own internal self-signed private CA and ignore these policies used by public CAs.

This proposal is by the CA/Browser forum.

They don't write standards that bind any CA public or private.

They write standards that the Browsers will throw warnings when a cert issued by any CA doesn't meet their standards.

Have fun with the InfoSec training explaining when end users should accept the security risk and when they shouldn't.

===============

Hey, I'm all over ADCS Autoenrollment (oh wait, our InfoSec group doesn't allow that and require manual requests (which I have scripted) followed by an email (scripted) for them to manually release (which once they do scripts complete the process...))

And I'm all over Let's Encrypt (same InfoSec group basically blew milk out their nose and scrambled trying to explain how it doesn't meet corporate standards for being a well-reputed commercial CA).

But even with that automation, I'm still left with situations such as:

-- Devs who claim their applications can't Intermediate / Root certs to validate and have to pin the public the certs;

-- Admins who claim likewise (really your six-figure Application Gateways can't possibly deal with certificate chains and need to pin a public cert?)

-- Federated organizations which don't check for SAML metadata updates and need to manually coordinate updating SAML signing certificates