When the cert expires, I renew it, insert new cert into the web server, close the case. What does this have to do with SSL encryption?
Web body mulls halving HTTPS cert lifetimes. That screaming in the distance is HTTPS cert sellers fearing orgs will bail for Let's Encrypt
CA/Browser Forum – an industry body of web browser makers, software developers, and security certificate issuers – is considering slashing the lifetime of HTTPS certs from 27 months to 13 months. The plan, floated at a meeting by Googler Ryan Sleevi earlier this year and still in its draft stages, comes just one year after the …
COMMENTS
-
-
Tuesday 13th August 2019 09:14 GMT Crypto Monad
> What does this have to do with SSL encryption?
It's more about SSL authentication. For example, remember when MD5 was broken: people were still issuing MD5-signed certs for a while after that, and then if the final signed cert had a 3-year lifetime, you had to trust MD5 signatures for another 3 years too.
-
-
Tuesday 13th August 2019 14:51 GMT Drew Scriver
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.
-
Tuesday 13th August 2019 15:47 GMT The First Dave
Re: Follow the money
"it's 2019. Automate already."
Quite apart from the technical difficulties with automatically renewing certificates for absolutely anything _other_ than a Linux/Unix box, how will that help if the cyphers etc are changing as frequently as the exercise suggests? You're going to have to update your update script every six months.
-
-
Tuesday 13th August 2019 19:15 GMT The Original Steve
Re: Follow the money
Whilst these tools are good for the most common use case scenarios, there's often very many other scenarios that aren't covered. And if I need to remember to do my Exchange, Skype for Business, IIS servers with multiple and complex cert bindings and other servers, the piss easy vanilla IIS boxes are hardly any bother to add to the list.
Tools to renew certs are all well and good, but generally they only renew the cert in the OS cert store and maybe IIS binding too. They are the vanilla and super easy ones.
Not forgetting certs that aren't issued by public CA's and devices that don't use Linux and Windows such as iLO/iDRAC, routers/firewalls etc.
When I was the Infrastructure Architect at a MSP a year or so back where everything was Windows based for our clients (at least that was critical in terms of certs) I ensured that we raised an automated alert when a cert on a box has less than 2 weeks left before it expires.
Helped prevent certs expiring and also caught the lazy engineers who never deleted the expired one post-renewal too.
-
Wednesday 14th August 2019 01:21 GMT eldakka
Re: Follow the money
Not forgetting certs that aren't issued by public CA's...
What is proposed is, I believe, a policy change to be followed by CAs on the issuance of certificates, not a change to the X.509 standard itself on what is a valid time to put in the notAfter field.If it's a cert not issued by a public CA, you can put whatever expiry you want on it, e.g. 10 years for an internal RnD box that you are only putting certs on so that its configuration is the same as production. RFC5280, S4.1.2.5 :
To indicate that a certificate has no well-defined expiration date, the notAfter SHOULD be assigned the GeneralizedTime value of 99993121235959Z.
which equates to 31 December 9999.
-
-
-
-
Tuesday 13th August 2019 16:14 GMT fwthinks
Re: Follow the money
Automation does not solve all the issues - you just move control of the certs from a person to a scheduled task but this process needs permissions to manage your certs and for example perform the LetEncypt challenge.
I am not saying it cannot be secured, but about understanding whether new risks are being created or existing risks being moved to another part of the process. So moving to a 3 month renewal could increase risks if you are not careful.
-
-
Tuesday 13th August 2019 19:39 GMT Donn Bly
Re: Has anyone here managed to get it working with IIS
I use WACS and it works great for IIS bound sites.
Over the last year I have converted most of my wildcard certificates to lets-encrypt single hostname certificates, and while most of my stuff is linux based (and was thus painless to implement) that also included having to deal with a couple of IIS servers. Win-Acme works great, just remember to copy it to a folder you can secure before you start evaluating it because it is a real pain to move afterwards.
Getting it to work for my windows-based SVN server, however, was a bit of a challenge. Ended up with a batch file that runs every week to export the current website certificate into a x509 certificate (using openssl), merge with the key and CA bundle, then compare the result to the file currently in use by Visual SVN. If they don't match, shut down SVN, replace the certificate file, and restart the svn and tomcat services.
All because there is a website and an SVN server with the same name (just different ports) on the same server and I couldn't get WACS to put the same certificate in multiple places in multiple formats.
-
-
-
Tuesday 13th August 2019 17:12 GMT Anonymous Coward
Some of us have scores of certificates on many different pieces of equipment performing different essential functions, running different operating systems, and having different update methods... not one cert on one web server.
Having to replace them twice as often would be a major waste of our time and effort. And yes, some of them are primarily used for encryption.
-
-
Wednesday 14th August 2019 19:58 GMT fidodogbreath
Re: Let's force frequent password changes too!
"Welcome to Hell. Your https certs expire every 13 months, your cert authority account password expires every 5 months, and your passwords for all 600 servers that you need to update expire every 90 days. Password managers are not allowed, because it's Hell."
-
-
Wednesday 14th August 2019 18:41 GMT Drew Scriver
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.
-
-
Tuesday 13th August 2019 04:23 GMT mbdrake
Certificate transparency/logging and CAA DNS records better than shortening cert lifespans?
Given the many different types of SSL/TLS certificates out there (as well as their different verification methods) alongside the multitude of devices which take SSL/TLS certs - automation of renewals is going to vary considerably. I think maybe a better approach might be to invest a bit more in the whole certificate transparency/logging system alongside the certificate authority authorisation DNS record to state which CAs can issue certificates for domains.
-
Tuesday 13th August 2019 05:49 GMT brotherelf
Re: Certificate transparency/logging and CAA DNS records better than shortening cert lifespans?
I'll grant them this: CAA is a time-of-issue check done by good-faith actors (with working software – not everybody's is). Once the certificate has been issued by whoever, CAA doesn't mean anything.
And CT is along the same lines: a public time-of-issue message published by good-faith actors. Yes, doing that might be a pre-requisite for getting into root certificate stores. Do we have technical certitude that $bigCA does not have mechanisms to bypass CT, if a three-letter agency with signed warrants compels them? No. (It would be in their own interest, though, to make it technically impossible.)
The thing you are looking for is the now-defunct (Chrome dropped support, Edge did not get support so far) HPKP HTTP public key pinning, which did not take off, because it actually forces you to think about what you're doing for two minutes, or otherwise your website will be unreachable for long timeframes if you are unprepared for a key change. (Also, technically it had a TOFU risk.) The hordes of "I click deploy on cloud" have overrun the greybeards.
-
Tuesday 13th August 2019 07:54 GMT DrXym
Re: Certificate transparency/logging and CAA DNS records better than shortening cert lifespans?
Or just allow websites to use self-signed or peer signed certs providing they're registered with SSL observatory first. Browsers that encounter a self-signed cert could look it up on the observatory and present the user with a one-time informational checklist of the site's security (yes it encrypts, yes it has been registered, no it hasn't been issued by a CA) without scaring them off.
-
-
Tuesday 13th August 2019 10:19 GMT mbdrake
Re: Certificate transparency/logging and CAA DNS records better than shortening cert lifespans?
I was thinking backend rather than frontend - and yeah, users don't care about the backend. But the point of view from site administrators, you want to do your best to reassure users that you give some kind of damn about the transmission of data.
But I can't think of an easier way of saying to a user "this site is slightly more trustworthy than a non-secure site because it has an SSL/TLS certificate, but the person or organisation behind this site could be as dogdy as hell" if Google keeps changing the display of URLs in the address bar, or removing the likes of the EV status from immediate view. I'd rather still have that info at a glance than hiding it. Clickers are going to click.
-
Tuesday 13th August 2019 18:04 GMT DrXym
Re: Certificate transparency/logging and CAA DNS records better than shortening cert lifespans?
Do you think your hypothetical gran understands why a website that has no encryption is waved through by the browser as fine but one which has a cert registered with SSL observatory is somehow worse?
Do you think your gran remotely understands the existing way browsers present certifcate information?
Do you think your gran understands what a CA is or why most browsers have HUNDREDS of CAs that they implicitly trust?
Please understand the point here. A self signed cert provides encryption and is still better than plaintext. But browsers frighten people about them. Why not allow them with a one-time consent if they're registered with SSL observatory.
Presenting this information to a user in a reasonable way is not insurmountable.
-
-
Tuesday 13th August 2019 18:55 GMT Orv
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.
-
-
-
-
Wednesday 14th August 2019 01:21 GMT eldakka
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 ;)
-
-
Tuesday 13th August 2019 07:41 GMT Pascal Monett
Money spinner
The use of that term indicates to me that security is not the primary goal of all this hoopla. Indeed, if it's security that is the issue, then I think LetsEncrypt is doing it right : you got a cert valid for 90 days that can autorenew for free.
If LetsEncrypt can do that, then why can't DigiCert and the rest of them ? Because they're in it for the money, security is just the cow they milk.
So here's your solution, DigiCert : go for 90 days auto-renewable, and turn your hefty fee into a yearly subscription without changing the cost to companies. You get your money, web sites get their certs, companies do not pay more, everyone is happy.
Except your Board, of course, who would have wanted to charge the yearly subscription to the 90-day charge, but you can go screw yourselves.
-
Tuesday 13th August 2019 08:00 GMT Anonymous Coward
I still wait for Let's Authenticate...
I'm really tired to read certs are for encryption. That's only half of their role. The other half is authentication. And when you can't trust a certificate owner, encryption too becomes quite useless.
Everybody is dumbing down certificates. Both those who made a business of selling certs to everybody for money without any vetting, and those so obsessed by 'government control' that are just helping it with certificates issued with almost no oversight.
Soon HTTS will be no safer than plain HTTP - you won't be able to trust any certificate. and soon I bet someone will start to sell some reputation service inside its browser....
-
Tuesday 13th August 2019 09:13 GMT John Robson
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.
-
Tuesday 13th August 2019 15:17 GMT Charles 9
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."
Not necessarily. What if the cert was stolen...or made using a stolen identity? Sure, the cert says it was issued to X, but how can you be sure X is X, just as how can you be sure Bob is really Bob and not Eve, Mallory, or Gene who took on Bob's identity?
-
Wednesday 14th August 2019 14:12 GMT John Robson
Re: I still wait for Let's Authenticate...
If you are assuming that people are using stolen certs then there is no authentication either.
The whole point is that the cert is considered sacrosanct, and it's secrecy protected at all costs - including nuking it (revoking it) if you suspect it has been compromised.
That's why short cert lifetimes are kinda-sorta useful. they force a refresh which should help in the case of an unknown theft (although of course the key under the doormat will likely still be there)
If it was made using a stolen identity then I'm still talking to the owner of the cert, even if they are lying about who they are. That's a different problem, and not one that the multiplicity of certificate authorities mitigates at all - in fact it makes it worse...
DNS based key distribution, with DNSSEC all the way up to the root at least gives you just one or two certs to trust implicitly (those at the DNS root) rather than the hundreds which are installed into every browser/OS by default.
I pretty much trust the admins of the root domain to do their jobs properly... DNSSEC key management is not difficult, so I can trust each stage - since the private certs are always held by the smaller of the entities we end up with a verifiable chain of trust from the administrators of the web server and DNS systems (yes, they have to talk to each other) to the root cert - which is very well protected indeed.
We don't need CAs at all any more...
-
-
-
Tuesday 13th August 2019 16:15 GMT Warm Braw
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.
-
Wednesday 14th August 2019 02:38 GMT doublelayer
Re: I still wait for Let's Authenticate...
That's a valid point, but it doesn't really affect the current situation. That is a perfectly valid reason not to allow self-signed certs, but nobody's suggesting that. As long as some degree of authentication is used, certs have a profound benefit to security by providing encryption. Letsencrypt does that; although it's mostly a DNS check to determine that the server in question has access to the domain, that will be enough to prevent MITM attacks. Shorter lifetimes doesn't really impact this either, and comes with some security benefits although those can be overstated.
-
Wednesday 14th August 2019 19:54 GMT Michael Wojcik
Re: I still wait for Let's Authenticate...
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.
For that matter, now that RSA is deprecated for key exchange by pretty much everyone, and the world is shifting to ECDH and other Kx protocols with forward secrecy, X.509 certificates often don't play any part in encryption regardless. In modern TLS (which is not the only, but by far the most common, use of X.509) certificates are primarily for authentication.
-
-
-
Tuesday 13th August 2019 17:20 GMT Anonymous Coward
Re: Money spinner
So if I get my hands on a server or other machine that is set up to auto-renew, does that mean it's now my cert?
And how would anyone else know, especially in a case where the domain name is up for grabs?
Think about defunct or bankrupt firms... or what you can do with the right burglar.
-
Wednesday 14th August 2019 02:47 GMT doublelayer
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.
-
Tuesday 13th August 2019 17:32 GMT IGnatius T Foobar !
Re: Money spinner
If LetsEncrypt can do that, then why can't DigiCert and the rest of them ? Because they're in it for the money, security is just the cow they milk.
Actually, the protocol used by LetsEncrypt can be used by DigiCert and the rest of them. It's an open standard and all open source software. There's nothing stopping DigiCert from selling you 5 years of service and then providing unattended, automatic certificate updates every 90 days, using the exact same software.
-
-
Tuesday 13th August 2019 07:51 GMT DrXym
Shakedown time
CAs are nothing more than a protection racket. I'm sure this has absolutely nothing to do with their profits.
Services like Let's Encrypt are a blessing but its still an onerous job to make them work. I think most site operators would wish they could have certs that expire after 5 or 10 years.
-
Tuesday 13th August 2019 13:05 GMT ettery
Re: Shakedown time
Good CAs who do the job they are paid for are a foundation of commerce on the internet. How else are you going to trust a website who's owner you don't know?
And for websites only looking to protect their clients with encryption, Let's Encrypt couldn't be easier (or cheaper). I use Let's Encrypt wherever possible and would happily expire my certs daily if it improved client safety.
Both are providing an important service.
-
Tuesday 13th August 2019 17:26 GMT Anonymous Coward
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.
-
-
Tuesday 13th August 2019 23:03 GMT Anonymous Coward
Re: Shakedown time
When I install a new browser, I actually spend a full lunchtime going through the CA list and disabling the shit out of it, only leaving the 3-4 big ones plus the small ones I actually use (my country's government CA and so on).
At a guess, perhaps once a year I get a certificate error due to a disabled authority, so clearly the list of preinstalled CAs could be *a lot* shorter.
It's a pity that you can't actually import/export the list of disabled CAs, so it's a manual job every time.
Maybe browsers could also ship with a list of trusted CAs but with most disabled by default, then present the user the choice to enable (bonus: just this certificate / the whole CA) when users start visiting HTTPS sites. After about two weeks you're unlikely to see another prompt for the next year or so.
-
Wednesday 14th August 2019 01:21 GMT eldakka
Re: Shakedown time
It's a pity that you can't actually import/export the list of disabled CAs, so it's a manual job every time.
Keep a copy of the certs you do trust. When you get a new browser (or it patches, which can update the list), delete all certs, and import your half-dozen saved trusted certs into the empty cert-store.
You can even save a copy of the entire cert database after you've customised it and just copy that over the top of the database in new installs. At least you could do that, not sure about the most recent versions of FF.
-
-
-
-
Tuesday 13th August 2019 07:56 GMT MJB7
IoT
I have an IoT device - specifically a wood pellet stove which I can control from my phone. Last year I had to upgrade the firmware "because of a change in the certificate". Now, for properly written IoT code (stop laughing at the back there), the firmware will hard code the CA root certificate and the server certificate can be updated as often as required. On the other hand, if you expect to upgrade the firmware every couple of years anyway, it's much easier to hard code the hash of the server cert directly, and just use a long-lived cert. That's not an option if you protect the server with a LetsEncrypt cert that rolls every three months. (On the other other hand, if you are using a hard-coded cert, you can just use a self-signed cert.)
-
Tuesday 13th August 2019 08:40 GMT Anonymous Coward
We moved from RapidSSL and it took a few hours
We had a wildcard SSL certificate from RapidSSL, cost us a £150 per year. Pretty easy to use but still, it cost money.
We moved to LetsEncrypt, took less than a day for all our servers (> 10) with around a dozen local IP addresses per server, cost one day of time and we never pay again. So it'll take approx one year to pay back and after than thats it. It just renews itself every 80-90 days or so. No fuss.
But also no cash cow for these certificate companies who do sod all for their money. The business model for Certificate companies is dead.
-
Tuesday 13th August 2019 10:12 GMT MJB7
Re: We moved from RapidSSL and it took a few hours
You are saying one employee day is worth £150? The usual figure is 200 working days per year, so that's £30,000 / year. Overheads (admin, rent, employer NI, employer pension contributions, etc) is roughly equal to salary, so that an employee being paid £15,000 / year.
For a full time employee (37.5 hours/week), if I have used the calculator correctly, the national minimum wage is about £16,000.
It's going to take several years to recoup the cost (still a decent ROI though).
-
-
Tuesday 13th August 2019 09:01 GMT Flywheel
Won't somebody think of the meetings ?!
perceived benefits of shorter certificate lifetimes will be offset by the added costs and headaches companies would encounter by having to renew their paid-for certificates roughly once a year
FFS .. whenever there's a cert change, I get drawn into meetings galore, and the email server starts to get hot just handing the extra guff that apparently needs to be discussed for a cert update. Right now I can handle this once every couple of years, but every year? Nooooooooo!
-
-
Wednesday 14th August 2019 01:21 GMT eldakka
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.
-
Wednesday 14th August 2019 02:54 GMT Olivier2553
Re: Won't somebody think of the meetings ?!
As it was mentioned, you can also decouple technical and financial part: pay once for a 2 years subscription (finance part) and get as many certificate renewals as needed during that period (technical part).
You don't even need to inform the manglement about the technical updates every 3 or 12 months, not more than you inform them every time you patch a system.
-
-
-
-
Tuesday 13th August 2019 09:29 GMT mark l 2
The days of these companies being able charge large amounts for certificates when all they are doing is a bit of basic admin is coming to an end.
The only checks most of these companies are interested in doing on is to ensure the payments clear and they aren't interested in verifying whether the person buying it is legitimate or not, so unless they are going to change the way they do things their business is going to get taken away more and more buy the free certs providers.
For a large proportion of websites letsencrypt certs are perfectly acceptable or if you use Cloudflare you can also get a free cert from them as well.
-
-
Tuesday 13th August 2019 10:53 GMT Crypto Monad
Re: DV's only
That's correct. EV certs are dead, since Chrome and Safari stopped displaying them, because users ignored them.
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.
In particular, it does not tell you anything about whether xyz.com is a good or bad actor, e.g. if you enter your credit card details they will be used for evil purposes or not. And it never did.
-
-
-
Wednesday 14th August 2019 14:26 GMT John Robson
Re: DV's only
>>a public key attached to the domain record in the DNS, signed by a trusted entity
>You know, that kind of sounds like something ... a web cert from a CA.
NO - It sounds like a DNS SEC record.
With the public key pushed to your standard DNS server - it can be self signed, since the public key is validated by you signing it with your DNS SEC key.
Which is validated by each subdomain up to the root.
It absolutely ties a cert to a domain - doesn't prove who owns that domain - but then I can get a cert for <glyph_substituted_bankname>.com quite easily at the moment - so this is no worse than the current situation.
The DNSSEC keys could be provided with authentication options.
-
-
Tuesday 13th August 2019 16:01 GMT Mike007
Re: DV's only
Because the browser vendors didn't want to support the standard. Something about not wanting to include a DNS library in the browser... an argument they stopped using when they actually did want to support a new standard.
It is commonly used for opportunistic encryption of SMTP transactions.
-
-
Tuesday 13th August 2019 13:05 GMT Anonymous Coward
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.
-
-
Wednesday 14th August 2019 09:06 GMT Anonymous Coward
Re: DV's only
The point it that it has to be All or Nothing. One weak link anywhere will break the whole chain, and an Outside the Envelope attack can pwn you just as easily as a MITM. IOW, you can't focus on any one aspect of the transaction: you need to focus on ALL of them, simultaneous and with equal attention, or the one you overlook becomes the one that gets you.
-
-
-
Wednesday 14th August 2019 19:56 GMT Michael Wojcik
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.
-
-
-
Tuesday 13th August 2019 09:49 GMT John Lilburne
An issue of Google's own making ...
... I'll have no part of it.
If you have no SSL cert there cannot be any issue of it being exploited, or having insecure encryption, or being applied to an abandoned site, or of it being stolen.
My website is like the majority of websites in that it is a persoanl blog that has no user signups, has no comment section, and has no purchase cart. It does not need a SSL cert of any description. Which is just another bit of software to deploy on the site and as such another vector for hackers to exploit. Here we are with a proposal by the SSL scammers and their enablers (Google, Mozilla, et al) to fix a problem of their own making.
-
Tuesday 13th August 2019 10:21 GMT MJB7
Re: An issue of Google's own making ...
My website is like the majority of websites in that it is a persoanl blog that has no user signups, has no comment section, and has no purchase cart.
I suspect that your website is in the majority in terms of count of websites. However, in terms of unique views, I suspect it is in a tiny proportion. Nearly all the blogs I visit have comment sections.
There are still cases for HTTP only websites (and yours is one of them), but I can't teach my mother to distinguish between when HTTP is safe, and when it is a scam. I *can* teach my mother to avoid a website that Chrome (other browsers are available) labels as "INSECURE". Chrome is going to have a hard time distinguishing between those sites which need to be HTTPS, and those that don't; it's not an unreasonable security trade-off to say "just make them all HTTPS".
-
Tuesday 13th August 2019 11:05 GMT Crypto Monad
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".
-
Tuesday 13th August 2019 15:03 GMT John Lilburne
Re: An issue of Google's own making ...
"Secure" (in the weak sense provided by HTTPS) is very different to "trustworthy".
Indeed 2 years ago I was doing some online banking from my desktop PC using the Barclay 2 factor device and got a page that was unexpected, some security thing or something. I rarerly do online banking but it looked slightly odd and I was unsure URL seemed OK but still ... went to the online chat with the bank (using the mobile phone) and described exactly what I was seeing and how I'd got there. Person on other end of chat log said "No its OK. Its a genuine Barclays page." "So I can to enter these numbers and press Ok", "Yes its alright." So I pressed Ok and out of the account went some £965. Sudden escalation of support up the system, and Barclays refunded the money about 12hrs later.
-
-
Tuesday 13th August 2019 15:03 GMT John Lilburne
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.
-
-
Tuesday 13th August 2019 19:03 GMT Orv
Re: An issue of Google's own making ...
I think the best argument for HTTPS for casual sites like that is to prevent ad injection by rogue ISPs (which these days is most of them). HTTPS will also prevent casual eavesdropping when people use public WiFi access points. It doesn't help security in this case, but it's good for privacy.
-
Wednesday 14th August 2019 09:08 GMT Charles 9
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.
-
Wednesday 14th August 2019 19:58 GMT Michael Wojcik
Re: An issue of Google's own making ...
In particular, it's trivial to inject Javascript malware into an HTTP connection. People who run NoScript and the like have some defense against that, but for most users it's a gimme. Everybody using unencrypted WiFi at a coffeeshop or the like is an easy target. Attackers can run cryptomining or try popular CSRF targets, etc.
-
-
-
-
Tuesday 13th August 2019 11:43 GMT Alister
perceived benefits of shorter certificate lifetimes will be offset by the added costs and headaches companies would encounter by having to renew their paid-for certificates roughly once a year
We only ever buy certificates for 1 year anyway, so it's not going to make any impact for us. We currently have 328 domains with certificates on them, with their expiry dates spread throughout the year, so slightly less than one a day has to be renewed - although they are clumped more than that.
-
-
Tuesday 13th August 2019 14:12 GMT localzuk
Re: Everyone's happy until...
Put it this way, they could charge $1 a year per domain and suddenly they're earning more than $100m a year in income. I don't know of any organisation that would go "hmm, nah, we don't want to pay $1, we'll switch back to the $150 a year company". Hell, make it $10 and most would still pay.
-
Tuesday 13th August 2019 13:02 GMT Anonymous Coward
SSL/TLS != Websites only
Worth remembering that SSL/TLS certs aren't only used by websites. While updating a cert on a website is a trivial exercise, once you start securing muti-server enviroments like Exchange, RDS or when signing remote app packages on multiple hosts, then it can become a lot more time consuming (especially when in some cases those operations can't be done without interupting user connections), especially where LetsEncrypt isn't possible / viable. Potential danger I see of decreasing the maximum age is that it may tilt the balance for some people between "let just secure everything" and "Hmmm, so which bits do we NEED to secure".
-
Tuesday 13th August 2019 13:36 GMT Stevem278
Encourages automation, increases security, reduces costs
This is great news, it will encourage businesses to move to more automated solutions with less user error. We used to use GoDaddy and annual renewal, rekeying etc. was an expensive pain. Now we use LetsEncrypt along with a few scripts and tools it's now free and automatic. So much easier!
-
Tuesday 13th August 2019 15:15 GMT Roland6
Re: Encourages automation, increases security, reduces costs
Looks like the beginning of Certificates-as-a-Service (CaaS).
That 90-days seems a bit long, reduce it to 45 days(*), which is more in keeping with monthly subscription payments. Now LetsEncrypt won't remain free, at some point it will need to make money, also they are doing all the work so that businesses (who earn money) can reduce costs, so naturally their backers will see sense and want a slice of that cost saving...
(*) Remember once-upon-a-time we were supposed to change our passwords every 4~6 weeks as it was supposed to enhance security; until someone did the research...
-
Wednesday 14th August 2019 03:03 GMT doublelayer
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.
-
Wednesday 14th August 2019 09:09 GMT Charles 9
Re: Encourages automation, increases security, reduces costs
But it's still infrastructure, and infrastructure costs money, both in acquisition and in upkeep. History shows gratis services like this usually can't stay up long-term unless something exceptional happens like a rich-but-charitable backer.
-
-
-
-
-
Wednesday 14th August 2019 02:02 GMT eldakka
Re: One nasty habit Google employees have
What do HTTP services care about public CA certificate issuing policy changes for?
What do intranets care about policy changes for public CAs? If you are using certs on intranet devices for HTTPS or TLS in general (or for whatever else you use X.509 certs for internally), you can set up your own internal self-signed private CA and ignore these policies used by public CAs.
-
Thursday 15th August 2019 16:39 GMT Dal90
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
-
-
-
Wednesday 14th August 2019 04:31 GMT streaky
Solution looking for a problem.
Title.
Also already moved a bunch of personal and corp certs to LE because hassle, think LE has reached the tipping point where there's not much reason not to if you don't really really need EV, code signing certs (which are equally ripe for disruption) and the like.
-
Wednesday 14th August 2019 17:00 GMT gnarlymarley
"Rapidly reducing certificate lifetimes to one year, or even less, has significant costs to many companies which rely on digital certificates to protect their systems," Hollebeek said.
This also introduces the possibility of human error and the actions need to take place more often then it previous would. Human error appears to be a large part of the problem too.
-
Friday 21st February 2020 21:24 GMT rcxb
For internal sites, I've already changed everything to self-signed, or rather our own certificate authority, because while a wildcard cert is cheap, the two year lifetimes are unnecessary maintenance burden.
The big reason we pay for certs for public facing sites is:
A) Doing it once every 2-3 years is manageable and poses less risk of something breaking when LE's auto-renew every month doesn't work quite right.
B) LE moved to be "more secure" which means dropping legacy browser support, which actually means making the web less secure for users who have good reasons to be unable to upgrade, and we certainly don't want to be unable to take their money due to browser choice.
Apple wants to eliminate both. The only real problem here is Apple. The best solution is to tell our Apple-using customers to switch to Firefox because Safari is broken. If that becomes untenable, then switching to LE is suddenly the least terrible alternative, and quickly, all other certificate authorities die out.