161–170 of 375 posts
I'd quite like to see this eventually getting to more like 1 month, maybe 7 days - forcing continuous automated issuance. Ideally, something more like 1 hour - like a JWT - would be nice, but not particularly practical as you need to allow some margin for incorrect local clocks time
Earlier quoted context omitted.
Why as a vendor would you use a self-signed certificate that causes the browser to scream at the customer when you could just not use TLS, plain old HTTP.
Because the alternative is to embed a TLS private key that would allow you to MITM every other one of those devices. Someone extracted it? Looks like you have to either (a) bury your head in the sand or (b) rollout an expensive recall to change certs on those devices. Why use slightly compromised HTTPS versus plaintext HTTP? Same reason they have those super cheap locks on diaries from the 90s: it's a deterrent. Make…
With the tightening of certificate trust, demise of self-signed certificates, etc., is there any remaining way to establish a consumer-oriented HTTPS server on a local network? Thinking of things like routers, printers, and self-hosted IoT devices here. Some of the label printers we support at work have simply atrocious workarounds to get them to work, and I'm wondering if it's the manufacturer's fault or if that use…
I'm not a huge fan of it, but, it seems like the way things are going is to simply run a service which is basically a large proxy. Your device connects out with some kind of persistent connection to their central service then requests to your device go to their server, which does AAA and routes to your local device. Fixes the SSL issue, avoids any NAT headaches, enables fully remote access and most importantly for PM…
Why would I even bother copying and distributing self-signed certificates if I can just properly get a certificate for my own personal router?
It’s idiotic that people still trust pure HTTP and have no option of switching.
Earlier quoted context omitted.
I admit, that's a solution, even if a very unpleasant one: Installing a custom root CA is intentionally complicated, so this is hardly doable as an onboarding experience. The setup must be repreated for every single client device that should access the server. There remains the question how I would get the CA certificate onto client devices in the first place. Lastly, with asking consumers to install a CA certificate…
> Lastly, with asking consumers to install a CA certificate, I ask for a significantly more powerful permission than if I could just have them trust my certificate. CA certificates can be constrained. https://tools.ietf.org/html/rfc5280#section-4.2.1.10
When I tried to use this many moons ago, most things ignored the constraints; although I could mark the extension critical, and then some (but not all, yay) of the things that didn't understand would refuse the CA.
Earlier quoted context omitted.
Do self-signed certs not work? Yes, you have to tell your browser to permanently accept them the first time you connect, but after that, they work.
Why as a vendor would you use a self-signed certificate that causes the browser to scream at the customer when you could just not use TLS, plain old HTTP.
Both Chrome / Chromium and Firefox have explicitly set policy that new features (as opposed to tidier ways to do things that already exist like DOM improvements) will require Secure Context, and there's already a weak assumption that even some tidying up will go into secure context when the rationale for not doing so is shaky (e.g. some of the web crypto features that needn't technically require Secure Context do anyway).
Earlier quoted context omitted.
Yeah those good old times when Comodo was hacked and issued certificates for gmail.com and nobody really cared. Or when some shady CAs sold intermediate certificates in devices so you could man in the middle all your network connections (and everyone else's, too). So bad those times are over and we have this browser cartell enforcing some basic security standards for TLS. Screw them!
Shortening the validity duration does not stop any of those issues. It just shortens the duration of a potential attack to one year.
We got plenty of gradual improvements over time. Validity time does not stop incidents, but it makes the impact smaller and allows ecosystem improvements to propagate faster.
Take for example Certificate Transparency, which is one of the most important ecosystem improvements. It was required for new certificates in 2018. But we still can't rely on Certificate Transparency logging for all certificates, as the certificate lifetimes were so long.
In the future such improvements will take maximum 1 year till all certificates have them.
Earlier quoted context omitted.
A less labor-intensive approach would be require CAs to revalidate the 'proof of ownership' basis of issued certificates monthly, and publish a revocation via CRL if the validation times out or fails for 1 month + 1 day. This would further encourage automation of the ecosystem without requiring redeployment in the cases where automated verification passes each month.
Misses the point. The concern is all historic traffic being vulnerable to a single encryption failure. Short cert lives make certain decloaking much, kuch more difficult.
Earlier quoted context omitted.
Sounds like CAs will be forced to keep shrinking cert length until everyone standardizes on 1 month. They no longer have any real power.
A less labor-intensive approach would be require CAs to revalidate the 'proof of ownership' basis of issued certificates monthly, and publish a revocation via CRL if the validation times out or fails for 1 month + 1 day. This would further encourage automation of the ecosystem without requiring redeployment in the cases where automated verification passes each month.
Anyone using email validation now needs to click a link every month, or their cert goes away.
I used to have the unfortunate task of managing a massive SAN cert used for white-label hosting with a bunch of our customer's domains.
Getting every single customer to get their tech person to look at the mailbox and click a link was often a multi-month process.
This may be good for security, but it is extra burden for small web developers and individuals. Big players will have cert renewals automated. It's possible and free for small players to use letsencrypt, that still takes some time to set up, manage and maintain over time. Without automation, you've got an annual chore to do or your site goes offline. I think some hosts are already starting to offer free and easy SSL…
Can you describe the kind of person who hosts their own website but cannot easily set up Let's Encrypt automatic renewal?
1) In my experience the user experience even for technical admins is still flakey on at least some popular platforms. In other words, it's not as incredible as you think.
2) It's not available to a host that doesn't connect to the internet but does occasionally get connected to by a local browser (eg. IoT firewalled inside my LAN is one obvious such case; I'm sure there are others).
And most importantly:
3) You'd have to be insane or naive to accept an architecture that leaves you dependant on a single vendor (especially if you need that vendor more than they need you!).