Submitted via IRC for Bytram
Let's Encrypt is the largest certificate authority by volume doling out more than 100,000 free domain certificates a day. The non-profit fulfills a noble mission of securing website communications that is applauded across the internet; it has raised the bar on SSL and TLS security, issuing 100 million HTTPS certificates as of June 2017.
However, despite industry accolades by privacy activists and praise from those in the security community for its mission, some critics are sounding alarm bells and warning that Let's Encrypt might be guilty of going too far, too fast, and delivering too much of a good thing without the right checks and balances in place.
[...] "Unsuspecting users might think they are communicating with trustworthy sites because the identity of the site has been validated by a CA, without realizing that these are just domain validation certificates with no assurance about the identity of the organization that owns the site," said Asif Karel, director of product management at Qualys.
[...] "Let's Encrypt can absolutely be abused," said Josh Aas, executive director of the Internet Security Research Group, the organization that oversees Let's Encrypt. "But so can't any other certificate authority. People act like Let's Encrypt is the first CA to be abused. This is preposterous."
[...] Jett and others applaud the accomplishments of Let's Encrypt, but believe the organization, founded by Mozilla, Cisco and the Electronic Frontier Foundation, is in a unique position to take a leadership role that could be used to crack down on certificate abuse when it comes to better vetting of applicants in order to weed out criminals.
Source: https://threatpost.com/free-certs-come-with-a-cost/126861/
Related Stories
Professor J. Alex Halderman, the noted election security researcher, along with his co-authors, have published a summary of Let's Encrypt, its components, and what it does. (Warning for PDF.) The service Let's Encrypt is a free, automated, open certificate authority (CA) to provide TLS certificates. These are usually for web sites, enabling them to provide HTTPS connections.
Since its launch in late 2015, Let's Encrypt has grown to become the world's largest HTTPS CA, accounting for more currently valid certificates than all other browser-trusted CAs combined. By January 2019, it had issued over 538 million certificates for 223 million domain names. We describe how we built Let's Encrypt, including the architecture of the CA software system (Boulder) and the structure of the organization that operates it (ISRG), and we discuss lessons learned from the experience. We also describe the design of ACME, the IETF-standard protocol we created to automate CA–server interactions and certificate issuance, and survey the diverse ecosystem of ACME clients, including Certbot, a software agent we created to automate HTTPS deployment. Finally, we measure Let's Encrypt's impact on the Web and the CA ecosystem. We hope that the success of Let's Encrypt can provide a model for further enhancements to the Web PKI and for future Internet security infrastructure.
[...] Prior to our work, a major barrier to wider HTTPS adoption was that deploying it was complicated, expensive, and error-prone for server operators. Let's Encrypt overcomes these through a strategy of automation: identity validation, certificate issuance, and server configuration are fully robotic, which also results in low marginal costs and enables the CA to provide certificates at no charge. We designed Let's Encrypt to scale to the size of the entire Web. In just over three years of operation, it is well on its way: it has issued over 538 million certificates and accounts for more valid browser-trusted certificates than all other CAs combined. We hope that in the near future, clients will start using HTTPS as the default Web transport. Eventually, we may marvel that there was ever a time when Web traffic traveled over the Internet as plaintext.
Let's Encrypt: An Automated Certificate Authority to Encrypt the Entire Web, Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, Pages 2473-2487 (DOI: 10.1145/3319535.3363192
Earlier on SN:
Let's Encrypt to Transition to ISRG Root (2019)
Three Years Later, Let's Encrypt Has Issued Over 380 Million HTTPS Certificates (2018)
Let's Encrypt is Now Officially Trusted by All Major Root Programs (2018)
Let's Encrypt Takes Free "Wildcard" Certificates Live (2018)
Free Certs Come With a Cost (2017)
Let's Encrypt Issues 100 Millionth Certificate (2017)
Let's Encrypt Won its Comodo Trademark Battle - but Now Fan Tools Must Rename (2016)
Let's Encrypt Gets Automation (2015)
(Score: 4, Insightful) by Arik on Thursday July 20 2017, @04:37AM (3 children)
Uh, no, they aren't.
This is a fundamental misunderstanding that seems to be shockingly common. An encryption certificate, at best, can establish identity, nothing more. Criminal background checks can be purchased separately when required, let's not try to bundle them.
If laughter is the best medicine, who are the best doctors?
(Score: 5, Interesting) by Fluffeh on Thursday July 20 2017, @05:22AM (2 children)
It does sound shockingly like they want the chap doing the gratis work to do a lot more than the guys charging for the same service.
I recall reading an interesting study once on the difference in expectations if something was given away for free versus having a stupidly low price-tag. Basically boiled down to if it was free, customers somehow perceived themselves as doing the vendor a favour by taking it. This means that they would complain about imperfections, want a full price service such as delivery etc. Whereas when they were paying for it, but a (way below cost) price that was next to free, they perceived that they were getting a fantastic deal. They did not complain about scratches, dings, and were exceptionally happy with getting it.
(Score: 2) by Pino P on Thursday July 20 2017, @02:27PM
So they'd report bugs rather than live with them? That sounds like a win-win.
(Score: 2) by DeathMonkey on Thursday July 20 2017, @05:46PM
I knew there was a reason I bought an SN subscription!
(Score: 1, Insightful) by Anonymous Coward on Thursday July 20 2017, @04:45AM (4 children)
Yes, we get it. Even though domain-validation certificates have been around for over a decade, Let's Encrypt is some sort of reckless menace for not providing extended-validation certificates, and thereby complicating the process enough to keep it from being free, and to keep people from using it if it were free.
You've convinced us all, now begone and collect your NSA paycheck.
(Score: 5, Insightful) by driverless on Thursday July 20 2017, @05:05AM (3 children)
It's not FUD, it's true! Free certs come at a cost to commercial CAs, who are being cheated out of revenue. Stay away from those nasty free certs and buy our expensive certs, they're... well they're just the same, but you're paying for them so there must be something there.
(Score: 1) by Revek on Thursday July 20 2017, @01:50PM (2 children)
Cheated like blacksmiths got cheated out of revenue when the horseless carriage came along? Or arcades got cheated out of revenue when the home game console came along? That argument is the weakest of all arguments concerning CA issuers. The real truth is that the for profit CA authorities are gouging money from their customers and not providing one thing extra. Lets encrypt has just shined a light on it. No ones getting cheated.
This page was generated by a Swarm of Roaming Elephants
(Score: 3, Informative) by Pino P on Thursday July 20 2017, @02:53PM
Unlike Let's Encrypt, which offers only domain-validated (DV) certificates, for-profit CAs offer organization-validated (OV) and Extended Validation certificates. This affects users of browsers and search engines that treat OV certificates differently from DV certificates:
(Score: 3, Informative) by Grishnakh on Thursday July 20 2017, @03:14PM
Whoosh! (I think) The OP was being sarcastic in case you didn't realize.
But no, it's not really like the blacksmiths and horseless carriages, because both cost money and one does a substantially different job than the other. It's more like free software vs. proprietary software: Microsoft is being cheated out of revenue every time someone installs Linux instead of purchasing a Windows license, and Adobe is being cheated out of revenue every time someone uses The GIMP or Krita, and IBM/Rational is being cheated out of revenue every time someone uses subversion or git. If you're looking for a non-software, non-computing analogy, I honestly can't think of one offhand, because I can't think of any other place where people give stuff away for free, without some kind of profit motive (like Google's "free" services, where they profit by advertising to you, or "free" cellphone apps which include ads). I suppose you could point to bottled-water companies being "cheated" of revenue when people drink tap water.
(Score: -1, Offtopic) by Anonymous Coward on Thursday July 20 2017, @04:50AM
Suck it
(Score: 1, Insightful) by Anonymous Coward on Thursday July 20 2017, @04:57AM
Nice Freudian slip.
(Score: 1, Insightful) by Anonymous Coward on Thursday July 20 2017, @04:59AM (4 children)
We can't use self-signed certs because the browsers scream blood murder. On the other hand, plain HTTP gets a pass.
Domain validation is slightly stronger in that the man-in-the-middle would have to intercept at least two connections; like Cloudflare.
(Score: 0) by Anonymous Coward on Thursday July 20 2017, @01:47PM
Self-signed should act just like HTTP. Anything loaded by a page that is either self-signed or HTTP should cause loss of the "secure" icon. No, this isn't the safest possible UI, but it's the safest viable one.
Aw heck, maybe do that for proper HTTPS too. Since any government can (by secret court order or similar) sign any domain, certificates are garbage anyway.
(Score: 4, Insightful) by Pino P on Thursday July 20 2017, @02:59PM (2 children)
Cleartext HTTP gives a true sense of insecurity, whereas self-signed HTTPS gives a false sense of security. True sense is better than false sense.
(Score: 0) by Anonymous Coward on Thursday July 20 2017, @05:50PM (1 child)
Self-signed certs are a form of opportunistic encryption (really, such certs are pointless and browsers should just be able to establish unauthenticated TLS sessions, but oh well). Such encryption schemes drastically reduce the threat of passive attacks like dragnet surveillance, when the parties involved are not being specifically targeted by an adversary. It is a massive improvement over plain HTTP!
(Score: 2) by Pino P on Thursday July 20 2017, @11:43PM
Browser publishers have seen that opportunistic encryption gives a false sense of security in general, whereas explicit non-use of encryption gives a true sense of insecurity.
As the adversary gains access to improved computing and networking performance over time, active dragnet attacks become almost as practical as passive attacks.
(Score: 3, Informative) by jmorris on Thursday July 20 2017, @05:00AM (27 children)
[rant on]
It is all bull crap. This mania for https on every ad, every static news article pageview, then watering down the cert process to the point it is useless so most of the small fry sites on the Internet wouldn't vanish. Captive WiFi portals are quickly becoming impossible as browsers don't want to even consider making an http connection to let the captive portal have a chance to grab it. And forget caching, url filtering or any of that other stuff that one needs or at least finds useful in the real world. I get it, the NSA is listening. But why do I care that they know I looked at the weather forecast? Most idiots are on Windows PCs anyway and security is only as strong as the weakest link.
But lets not single out Lets Encrypt! for abuse. Bought an SSL cert lately? Other than a credit card on file somewhere to confirm the payment of the token fee, all it proves is that the person buying the cert had control of the web server for at least the brief moment the purchase occurred on. Haven't tried it but I suspect they would accept a prepaid Visa card just as readily, just as long as the money was good. And so many entities are in the typical browser list of CAs that only a fool or a paranoid who actually examines the certs for sites they visit would trust this broken system.
[rant off]
(Score: 0) by Anonymous Coward on Thursday July 20 2017, @05:11AM (2 children)
People think that little padlock actually means "I'm talking to someone genuine"? Really? I thought it just meant "the connection between me and the remote machine is encrypted so that only me, the remote machine, anyone who could get their hands on the certificate, along with my ISP, any government agency worth its salt, anyone able to MITM me, and this guy called Mike can read the traffic as cleartext"
(Score: 2) by bob_super on Thursday July 20 2017, @06:16AM
Many people probably barely notice the padlock.
The overwhelming majority of those who do, believe that it means they're safe typing their bank/mail/social passwords.
Go ahead, try talking to the average internet user about certificate authority. I've got lots of popcorn, a camera, and we can teach Hollywood how to make comedies ...
(Score: 1, Insightful) by Anonymous Coward on Thursday July 20 2017, @07:32AM
I thought the padlock meant "someone added a GIF of a padlock", and I have thought so ever since Javascript got the ability to open new browser windows with nothing but window decorations.
(Score: 3, Insightful) by kaszz on Thursday July 20 2017, @05:12AM (8 children)
HTTP was built on trust. That is gone and thus HTTPS it is.
(Score: 3, Insightful) by jmorris on Thursday July 20 2017, @05:36AM (7 children)
You just proved my point. https means secure? When most people are on machines infected with malware reporting all their activity to a U.S. based megacorp? And the rest are either on Apple's closed spyware platform or Google's pervasive surveillance OS / Browser? Security is based on the weakest link. And in most cases, even on a http link the actual connection between the browser and Cloudflare isn't the weakest part.
There is no such thing as a free lunch though. Even if the side effects I already listed don't bother you, consider how much energy we waste pointlessly encrypting things and decrypting them. Imagine a guy just wanting to look at a random webpage. The site encrypts it, his wireless access point wraps the whole thing in another later of encryption and then his poor tablet has to do a pair of decryption passes, often on differing hardware with differing efficiency, on BATTERY POWER. Then when the browser caches the page the flash layer might encrypt it again. The extra load on the servers is bad enough, but battery life is the #1 problem facing the mobile world at the moment.
(Score: 2) by kaszz on Thursday July 20 2017, @05:54AM (3 children)
Https means more secure, not fully secure. People with sane OS and browser choices have very little malware. That some website owner makes poor choice of provider should not be used to establish bad protocols that hamstring those that make better choices.
The energy issue can be handled with proper hardware. Encryption using ASIC or FPGA is quite efficient. This goes both for WPA2 and TLS. The flash layer shouldn't bother with encryption so that is a pure implementation issue that is way easier to change than transport encryption or wireless encryption.
(Score: 2) by Grishnakh on Thursday July 20 2017, @03:20PM (2 children)
You can't do encryption with ASICs or FPGAs in a consumer device. Encryption algorithms only have so much shelf-life; after a while, they're broken, or deemed too insecure. There's no way to standardize on one for some huge length of time so it can be baked into an ASIC and used in a device that could be used for the next 10 years. FPGAs would be better, but if the new crypto algorithm is too complex, it won't fit. And besides, it's completely impossible to use an FPGA in a consumer device anyway: they're simply too expensive. That's why they're only used in military applications, or high-cost/low-volume/high-performance applications like telco equipment.
(Score: 0) by Anonymous Coward on Thursday July 20 2017, @03:59PM
FPGAs too expensive? You can get FPGAs starting at $10 and they are used in more things than you probably realize. This is especially so when you look at more recent technology because it is easier to have an FPGA than it is to do the fancy stuff on custom silicon or wholly in software.
(Score: 0) by Anonymous Coward on Thursday July 20 2017, @07:29PM
> You can't do encryption with ASICs or FPGAs in a consumer device.
Cryptographic accelerator cards for servers already exist (example [netgate.com]). Consumer devices have acceleration baked into the processor: [wikipedia.org]
(Score: 2) by FakeBeldin on Thursday July 20 2017, @09:12AM
Wow, you must really have seen very little of the web since 1996. Pointless gimmicks on websites have become the norm!
the average webpage nowadays has the size of the original Doom executable [wired.com]!
Commenting on news in your favourite echo chamber (whether it be a green site, a red site, or a reddit site) has become a time sink for many people! Talk about loss of efficiency and waste...
And you talk about encryption being pointless? Puh-lease, the web wastes far, FAR more energy due to other things.
(Score: 0) by Anonymous Coward on Thursday July 20 2017, @09:41AM (1 child)
HTTPS means secured connection HTTP. It says diddly squat about the state of the machines at either end. It simply says that the connection between the two endpoints cannot be eavesdropped or modified. Like the ultimate sealed envelope. But a sealed envelope doesn't preclude either side from reading it on the radio, does it?
(Score: 2) by Scrutinizer on Thursday July 20 2017, @05:06PM
Unfortunately, you're incorrect. The HTTPS/Certificate Authority model is completely broken when a trusted CA is compromised by a man-in-the-middle attacker. It doesn't matter if the CA is compromised by a criminal cracker or a criminal government agency (NSA for the USA; equivalents for China, Russia, etc.). If this seems a strange claim to you, reader, then take a look at how many CAs your browser and/or operating system trusts by default, and where all those CAs are located.
Internet networks will need to be completely redesigned to enable truly secure communications. Some plans along these lines are being promoted at youbroketheinternet.org [youbroketheinternet.org].
(Score: 3, Insightful) by maxwell demon on Thursday July 20 2017, @05:45AM (5 children)
You say that as if it were a bad thing. Captive portals are a pain in the ass. They are a kludge that should never have become widespread. The sooner they are replaced with a sane technology, the better.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by kaszz on Thursday July 20 2017, @06:00AM (4 children)
Even better. They could have their own proper protocol.. The horror ;-)
Something like ICMP-captive etc. That would also make it a lot easier for terminals that only features a telnet tool and no browser.
From:
To:
And the same goes for other services that don't talk any tcp-http-html yuck at all.
(Score: 0) by Anonymous Coward on Thursday July 20 2017, @06:49AM (3 children)
How does your proposed captive crap protocol display the Terms Of Service and prompt for acceptance?
(Score: 2) by kaszz on Thursday July 20 2017, @07:07AM
"Captive agreement supported: XY21, FR5, R2" ?
Or "Captive agreement supported: free use, max 1G/h, ..". Or just some readme.
(Score: 1, Insightful) by Anonymous Coward on Thursday July 20 2017, @12:37PM (1 child)
The same way it provides you with the required username and password?
(Score: 0) by Anonymous Coward on Thursday July 20 2017, @03:49PM
So.......a web page. Not exactly an improvement.
(Score: 0) by Anonymous Coward on Thursday July 20 2017, @06:33AM (1 child)
It does not however provide what is REALLY needed for most websites, which is authentication of the origin of the scripts. Stealing a hostkey on every virtual webserver for a site is easy. What would be hard is stealing an offline javascript signing key that was only used to sign production ready versions of javascript, with browsers providing a method to pin/log/authenticate the script against a file size+checksum+signature, thus ensuring the origin of the script was from the expected source, and that any changes in script versions between sessions were disclosed by the browser to the end user, so they can determine if there is a reason for concern.
Personally javascript concerns me far more than the possibility of a MITM at this point in time, since given a rogue javascript being sourced in by a website, especially cross-site scripts like google telemetry or similiar could have far wider ranging effects both on my browser security and the integrity of the data I am accessing or attempting to submit to a website.
(Score: 2) by Pino P on Thursday July 20 2017, @03:35PM
How would this "method to pin/log/authenticate the script" work without requiring hobbyists and startups to pay hundreds of dollars per year for a code signing certificate? And how would it work for a developer tool such as JSFiddle, which runs user-entered scripts as its primary functionality, or a site like Wikipedia, which lets a registered editor paste editing aid scripts into his user page?
(Score: 3, Insightful) by TheRaven on Thursday July 20 2017, @08:01AM (4 children)
Good. Captive portals are actively dangerous anyway. They work on the assumption that any HTTP connection is a web browser and so it's safe to intercept it. They cause random breakage for other things that poll HTTP and suddenly get back nonsense that they weren't expected to parse. To work around this, operating system vendors have to suspend normal networking functionality, try an HTTP connection to a well-known URL, and if this doesn't give the response they expect then forward it to the web browser. Additionally, because the captive portals addresses are not public addresses they typically don't have proper (or, indeed, any) SSL certificates and so it's trivial to spoof them and get people to enter their credentials into an untrusted site.
Most of these are only useful on the client or server (reverse proxy or CDN) side. Caching for an individual client is useful because it lets you completely bypass the network and because most users visit the same sites multiple times. Caching at the network level hasn't been a win for over a decade: the long tail of content is large enough that you miss in the cache a lot more than you hit and the cost of maintaining the cache is more than the cost of the off-network bandwidth that you save. URL filtering is similarly easy on the client side, which is where modern web browsers do it.
Looking at the weather forecast gives a high degree of accuracy location-prediction information: most people look at weather forecasts for places that they're going to be at the time that they're requesting the forecast for. The NSA might not care, but the thiefs snooping your WiFi connection are interested in when you're going to be away from the house, the ISP snooping your connection to sell ads is interested in when and where you might go on holiday, and so on.
sudo mod me up
(Score: 2) by Pino P on Thursday July 20 2017, @03:21PM (3 children)
But can you think of a less dangerous way to present terms of use to users of bring-your-own devices and solicit a user's acceptance of said terms?
Which won't help when fans of cleartext HTTP contrive situations involving maximally cacheable responses over maximally expensive connections, such as two dozen students in the same classroom in poor sub-Saharan Africa viewing the same Wikipedia article [codinghorror.com].
Which breaks in cases of bring your own device.
(Score: 0) by Anonymous Coward on Thursday July 20 2017, @04:19PM
Yes, they should have a dedicated protocol for presenting them. Your device connects to a network, it does its DHCP request, gets the network configured, then fires of a ICP (or whatever people decide to call it) request, the response for that includes the necessary information to pop up a dedicated window in your OS to enter credentials, once an accepted reply is received, the stack issues a new DHCP request and new ICP request, if it receives notice that it isn't required, then proceed as usual and mark the network as up.
The benefit with this is that the OS can know for sure that the network isn't up and all DNS or other requests will fail.
(Score: 2) by TheRaven on Sunday July 23 2017, @05:29PM (1 child)
Sure. Write 'by connecting to this network, you accept the terms of use' on the piece of paper that you give them with their login credentials. There is a lot more precedent for this kind of agreement having legal force than for a click-through agreement.
sudo mod me up
(Score: 2) by Pino P on Sunday July 23 2017, @10:09PM
Have you tested this policy in an actual restaurant? As I understand it, customers don't expect to have to physically stand in line for credentials. They expect to use the hotspot to pass the time while standing in line to place an order (in the case of a quick-service restaurant) or for a seat (in the case of a sit-down restaurant).
(Score: 0) by Anonymous Coward on Thursday July 20 2017, @09:07AM
Because you should be opposed to them spying on you without a valid warrant for any reason, regardless of whether or not what you're doing is trivial. Mass surveillance is inherently revolting.
(Score: 2) by Pino P on Thursday July 20 2017, @03:12PM
Since when? Last time I tried Firefox on a hotspot with a captive portal, I got a message to the effect that this connection requires users to sign in. Unfortunately, I forget the exact wording, but based on the bug list at Mozilla's page about captive portal detection [mozilla.org], it appears to be live since Firefox 52.
If you operate an ISP in a remote area with a slow and/or harshly capped upstream [codinghorror.com], you could run an internal CA on your intercepting caching proxy, and install the corresponding root certificate on all subscribers' devices. However, this may not work for devices running Android 7 or later, which ignore user-installed certificates unless an app explicitly opts into using them.
They care that you looked at the weather forecast for a place in the region that happens to be considered "terrorist haven" this decade.
Unless you've set your TLS client to distrust certificates without an organization name and address.
(Score: 3, Interesting) by kaszz on Thursday July 20 2017, @05:09AM (15 children)
So display a different color on the currently green padlock for let's encrypt CA and perhaps others that are deemed less hard on verification. It may even display a shortname for the CA? how preposterous suggestion to inform users about what's up....
(like that the current situation allows China authorize your bank.. pinning anyone?)
A peer-to-peer model with trust chains seems better, but perhaps slower to update. Any ideas?
DNSSEC will still put DNS operators as the benevolent.. and they get hacked [soylentnews.org].
Besides the model where browser writers are benevolent dictators on who are allowed to become CA and then any CA may impersonate any other at will. Just sucks.
(Score: 2) by JNCF on Thursday July 20 2017, @06:27AM (5 children)
No trust chains, just a blockchain: Namecoin. [namecoin.org]
(Score: 2) by kaszz on Thursday July 20 2017, @07:03AM (4 children)
Wouldn't that use lots of resources compared to A certifies B that certifies C, so a user that trust A will trust C ?
(Score: 2) by JNCF on Thursday July 20 2017, @07:54AM (3 children)
Oh yeah, undeniably. But the user doesn't have to trust A, or whatever government A resides in the land of. It's a trade-off. I feel like this is one of the most compelling use cases for a blockchain.
(Score: 2) by kaszz on Thursday July 20 2017, @03:35PM (2 children)
My idea is more like this:
A --> B --> C --> D
C --> A
E --> C --> F --> D
And so on. And not government "A". It would anyway be treated like any other node and not given any special privileges.
(Score: 2) by JNCF on Thursday July 20 2017, @04:13PM (1 child)
Each additional parent certificate in the chain is a potential point of failure. If a user simply trusts C, we only have 1 point of failure (speculation about blockchains imploding aside). Either that specific name/key is compromised, or we're golden. My point about governments is just that they can forcefully take the keys of any entity they've identified in their territory, so having a potential point of failure in those boundaries opens you up to all the shenanigans that TLAs can currently play with HTTPS -- potential points of failure aren't ok just because you actually trust them, anybody could be compromised at any time. I got that you weren't proposing government involvement. There are certainly times when a web of trust seems more reasonable than a blockchain, but I don't know if global domain and public key registration are one of them.
(Score: 2) by kaszz on Thursday July 20 2017, @04:24PM
Of course this scheme would require people to have trustees outside of one territory. Preferably at least one in each power region.
(Score: 0) by Anonymous Coward on Thursday July 20 2017, @07:36AM
You mean like the address bar is already displayed in green for extended validation certificates and white for domain only certificates?
(Score: 2) by TheRaven on Thursday July 20 2017, @08:06AM (2 children)
Browsers already display different colours for EV certs. For example, going to Soylent I see a grey padlock, but going to PayPal I see a green one along with 'PayPal, inc', the name of the organisation for whom the extended validation was carried out, so I can be fairly confident that I'm actually talking to PayPal (though, apparently, it's possible to register a punycode domain name with the padlock emoji in it, which makes it a bit harder now that browsers have stopped displaying URLs sensibly with different components in different places and the padlock in a box to one side).
Certificate Transparency is better for that, as it lets you tell if the cert that you've seen is different from the one other people have seen and lets the domain owner see if anyone has seen certs that are not issued on their behalf (and if a CA is caught doing this a few times they'll find that browsers no longer trust them).
sudo mod me up
(Score: 2) by kaszz on Thursday July 20 2017, @03:42PM (1 child)
How does it distribute this information?
Anyway, it should be possible to pin certificates to only be authorized for specific domains. Ie so China can't authorize an American bank etc.
(Score: 2) by TheRaven on Sunday July 23 2017, @05:27PM
Via a shared Merkel tree. There are also web gateways that allow anyone to check the CT records without needing a special client.
Certificate Transparency solves a generalisation of that problem.
sudo mod me up
(Score: 0) by Anonymous Coward on Thursday July 20 2017, @11:06AM (1 child)
Please, at least get the facts straight.
1. DNS operators didn't get hacked
2. Registry != DNS
3. Resellers or whatever not using TLS at all for communication of sensitive information, well, you have a problem.
4. DNSSEC reduces number of CA from current 'quintillion' to exactly 1. And then you have your chain of trust. So unless you want to change the keys for all of .com, well, it will be really fucking difficult to alter some-domain.com. You can't MITM that stuff as easily as with CA model, not by a long shot.
5. DNSSEC allows domain validation via DNS + CA validation via current CA model. You know, 2x validation is better than whatever we have now.
(Score: 2) by kaszz on Thursday July 20 2017, @03:46PM
Technically the DNS server didn't get hacked but in practice it matters less.
So one fuckup and a whole domain goes?
It increases complexity => more mistakes. It's better with one primary model that really works on its own.
(Score: 2) by Pino P on Thursday July 20 2017, @03:27PM (2 children)
I foresee two practical problems with the peer-to-peer web of trust model.
(Score: 2) by kaszz on Thursday July 20 2017, @03:51PM (1 child)
So you specify that this vetting is only for B being B not recursive vetting?
Don't rely on key signing parties but reputation over time. A party that has been reliable over a long time tend to continue to be that. Like if I can see that say eBay have provided a decent business for a few years. Maybe I will trust them enough to try them out even if I don't know them personally.
(Score: 2) by Pino P on Thursday July 20 2017, @11:38PM
As I understand it, this would be analogous to the flag cA=FALSE in the basic constraints section of an X.509 certificate. But if all or most key-signing party attendees set the non-recursive flag, this diminishes the "friend-of-a-friend" feature of the web of trust.
Which the Windows SmartScreen Application Reputation feature attempts to provide, as does the reputation factor in mail servers' spam rejection formulas. But if almost nobody is willing to communicate with someone who has not already earned reputation, then how should someone new to a particular community earn reputation for the first time?
(Score: 3, Informative) by bradley13 on Thursday July 20 2017, @05:52AM (4 children)
It is not the fault of LetsEncrypt if people don't know what the padlock icon actually means, i.e., "data-transmission to the server secured". If it's actually important for people to know whether or not the identity of the server itself has been verified, then it's on the browser-manufacturers to make this distinction clear, perhaps by displaying a completely different icon.
But really, even that is insufficient. As long as every CA can create root certificates for every domain, the entire security system is fundamentally broken. For grins, I just skimmed at the current Firefox list. Known abusers like CNNIC and Symantec are still listed. Since when is Visa a root CA? Why should the whole world trust the HongKong Post Office? If someone wants to set up an MITM attack, some CA somewhere can be bribed to issue the necessary certificate.
Everyone is somebody else's weirdo.
(Score: 3, Interesting) by TheLink on Thursday July 20 2017, @07:19AM
Actually the ssh system is more secure than the CA "feel good" bullshit.
Firefox can be configured to be a bit more secure since you can disable all the CAs you don't trust. But you might have to disable all or nearly all CAs since CAs often sign each other's certs (e.g. Entrust has signed CNNIC's cert before: https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/e6UcpJ3g9s8 [google.com] )
With IE and Chrome on Windows (AFAIK Chrome uses the Windows cert infra) you can't do that:
https://www.proper.com/root-cert-problem/ [proper.com]
Disabling or revoking the known bad certs helps a bit BUT doesn't help for new bad certs that you don't know of. So if CNNIC has another CA cert signed by a different CA that you haven't disabled, all certs signed by that CNNIC CA cert will be trusted by IE/Chrome on Windows.
Certificate pinning helps but it's more a kludge than a real solution.
To me a real solution is for the browser to warn the users if the cert or CA changes unexpectedly. Just like the ssh system. Yes that still won't help many users but I'm not sure if there's anything that will actually help those users - they'll just click through the warnings anyway. ;)
(Score: 1) by ewk on Thursday July 20 2017, @07:20AM (2 children)
Nothing is stopping you (or anybody else for that matter) in cleaning out the initial trusted root-CA list in Firefox...
Then only add back the ones YOU really trust when FF starts warning you about a certificate form an untrusted CA's
I don't always react, but when I do, I do it on SoylentNews
(Score: 2) by kaszz on Thursday July 20 2017, @03:53PM (1 child)
The builtin tools to handle the builtin CA list sucks..
(Score: 1) by ewk on Friday July 21 2017, @09:42AM
You have the source... built better ones :-)
I don't always react, but when I do, I do it on SoylentNews
(Score: 2) by KritonK on Thursday July 20 2017, @10:41AM (3 children)
What they really mean is that Let' Encrypt provides only class 1 SSL certificates, which verify only that the certificate holder controls the domain for which the certificate was issued. The implication is that we should be buying class2 and class 3 certificates from them, instead of getting free class 1 certificates from Let's Encrypt. Presumably, thanks to Let's Encrypt, nobody pays for class 1 certificates any more, and certificate issuers' profits have plummeted.
For me, the hidden cost of free certificates is the cost of the infrastructure, required to run Let's Encrypt, which is probably not negligible.
(Score: 2) by Thexalon on Thursday July 20 2017, @11:30AM
Yup: What they really mean is "Waaaaa! This organization is ruining our business model by providing for free a service that used to be one of our cash cows! Please believe these guys are horrible, no good, very bad, and you should continue to pay for something you can get for free!"
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 1) by kai_h on Friday July 21 2017, @09:35AM (1 child)
I don't know about that. I recently set up an nginx web server on a Ubnutu virtual machine. After getting the web server up and running, it literally took me 10 minutes to set up LetsEncrypt and create a cron job to renew my certificates on a regular basis. Done.
This is much easier than the usual way which is to create a CSR (certificate signing request) in your web server of choice, get the CSR signed and, have a cert generated and then import this back into the web server - a task that I would otherwise only be performing once a ear at most, so would have to re-remember how to do it all over again every time the renewal comes around.
(Score: 2) by KritonK on Monday July 24 2017, @08:20AM
I wasn't referring to our infrastructure as Let's Encrypt users, but to Let's Encrypt's own infrastructure. Certbot communicates with Let's Encrypt's servers, which cost money to operate. There's also the cost of developing and maintaining certbot and the corresponding server software.
(Score: 1) by Revek on Thursday July 20 2017, @01:20PM
That is what all I can think of when I hear someone bashing let encrypt. The slickest of them praise while pointing out its imperfections.
This page was generated by a Swarm of Roaming Elephants