Starting Today, Google Chrome Will Show Warnings for Non-Logged SSL Certificates (bleepingcomputer.com) 172
Starting today, Google Chrome will show a full-page warning whenever users are accessing an HTTPS website that's using an SSL certificate that has not been logged in a public Certificate Transparency (CT) log. From a report: By doing so, Chrome becomes the first browser to implement support for the Certificate Transparency Log Policy. Other browser makers have also agreed to support this mechanism in the future, albeit they have not provided more details. This new policy was first proposed by Google engineers in 2016, and was scheduled to enter into effect in October 2017, but was later delayed for 2018.
this is starting to feel like email (Score:3)
Re: (Score:3, Insightful)
Gotta keep throwing up those barriers to entry. Can't have the small fry getting in on Google's take, now can we?
Another Google metadata sink? (Score:4, Insightful)
So how is this going to be implemented? Every SSL cert is going to be sent to Google for "verification" or is the CT log going to be local and the browser will just search it every time?
Comment removed (Score:5, Interesting)
Re:Another Google metadata sink? (Score:5, Insightful)
Re:Another Google metadata sink? (Score:5, Insightful)
You shouldn't be doing that, your networking devices should have proper certs or your client system should be configured to trust a corporate CA and the network devices then have certs from that. Chances are your job requires you to have elevated privileges on all manner of important networking devices, if someone was able to MITM you they could steal some powerful credentials.
The only times you should be logging into a device that uses a self signed cert are:
1, initial configuration
2, testing
In the same vein however, it seems browsers are disabling support for weaker algorithms by default, and preventing you from turning them back on. This represents a significant problem, as there are all kinds of old devices which we still need to access for various reasons.
Re:Another Google metadata sink? (Score:5, Insightful)
Are you joking? Self-signed certificates are secure, arguably more secure than commercial CA-signed certificates because I had to register each and every one with the browser. I created the certs myself. A MITM attack is *instantly* detectable to browsers (and to me), unlike a MITM attack using bonafide signed certificates from a breached certificate authority. Browsers make using self-signed certificates somewhat awkward, which is unfortunate. Firefox tells me, incorrectly, that my self-signed certificate is not secure. That is complete nonsense of course.
Another secure method is to sign with your own certificate authority. Then you just have to convince the browser once to take your CA cert. Like the self-signed certificates, MITM attacks are instantly detectable. This method is preferable to self-signed certs when you have deal with more than a few.
In my mind for internal servers and devices, my own certificate authority is far more secure than using something like Let's Encrypt.
Re:Another Google metadata sink? (Score:5, Interesting)
The CA model is particularly bad for 'internal' devices.
So one, for internal communications inside a home network, the warning is so scary that some devices decline to support https just to avoid the support call because a web browser called the device 'insecure'. Note that https with bad cert is considered 'terribly insecure to the point of blocking the site' and http without any cert whatsoever is 'ok'. Home networks are not going to go through the rigmarole of all this.
For another, my internal IT department is given the ability to sign a certificate for *any* site I visit to provide support for internal devices. I am not empowered as a user to elect to impose my own nameConstraints as I import the certificate, so to secure access to router.internal.mycompany.com, I give them access to impersonate my.bank.com
Even when the IT department has ability to sign certificates, either it's going to be uselessly lax (automatic granting of certs for whatever reason) or impractically difficult (every sign requires tedious interactions). Companies are terrible about implementing the right balance internally.
Assuming you overcame all this, you *still* will get a warning, because that internal IT department isn't going to have it registered in a CT log. If they *do*, then others can audit that log to discern details about their network and they have *another* class of security problem to tackle. Or chrome is deployed with a policy to disable this feature for the sake of the internal devices, *again* coming back to fixing internal network behavior requiring reducing security for the wider internet.
The problem is that roughly all discussions on this front focus on the typical 'internet' usage and fail to conceive of approaches that would make sense for internal networks.
Re: (Score:3)
One amendment, that CT policy is better than I presumed it would be:
http://www.chromium.org/admini... [chromium.org]
Would have been nice to link in the article, it took me a while to find it. So this provides a more targeted way to relax the CT, which can in turn limit the efficacy of that internal CA, so it seems to be a step in the positive direction.
Good to see progress being made in limiting the collateral damage enabling https internally can inflict, but it's still in many ways convoluted and an ill fit for how many
Re: (Score:2)
Of course, you would have to securely carry over that cert. At that point it wouldn't matter if it were self signed or not, it's more like managing an ssh host key. Problem is that in practice, people will click 'yes'. Chrome sucks in the regard of not allowing me to mark a specific fingerprint as 'valid' regardless of CA validation.
Re: (Score:2)
For my part I don't take issue with the concept that at this point encryption and integrity assurance for this sort of traffic, even internal isn't such a bad idea. Aspiring to have an internal network that isn't going to be compromised at the IP or DNS level is a good goal, but to the extent possible success should not be assumed. As such it would be bad form to assume a network to be 'trusted' if at all possible.
As it stands, not many folks will say 'ssh is stupid, just use telnet' because the key manag
Re:Another Google metadata sink? (Score:4, Informative)
Also what about locally signed certificates, using a corporate or Intranet CA, that's installed on all computers that might use those certs?
That was, at one point, considered a best practice, but I assume this'll break that.
This, from TFA (I know, right?): "Google engineers have also added a Chrome policy flag that allows sysadmins to disable the CT log-checking behavior in instances Chrome is deployed inside an intranet."
Re: Another Google metadata sink? (Score:2)
Probably on a per host basis, like some of the other exceptions required to operate with the shitty embedded web servers in equipment that don't get updates so are still pre poodle etc. Not really ideal when you have a few hundred or maybee a few thousand.
Re: (Score:2)
http://www.chromium.org/admini... [chromium.org]
Seemingly on a domain level. So long as you have domain names...
It would be interesting to treat IP based urls different from name based urls somehow... or at least private and link local addresses somehow differently (unless resolved by name)
Scam (Score:2)
This seems more and more like an effort to compel website owner/operators to buy into the SSL certificate scheme.
Revenue.
Re: (Score:2, Informative)
You know you can get a ssl cert for free and have it configured in like 30 seconds with certbot, right?
Re: (Score:2)
And join the debate over whether these free alternatives are legit, or fight over whether I should have an EV instead of a DV cert, or wait for say Lets Encrypt get hammered by the cert vigilantes and have to eventually join in and pay so I can be part of the SSL charade?
If it were so simple.
Re: (Score:2)
Look at the impact of GDPR on the WHOIS database. On the face of it, ICANN merely has to shut down the public database and that leaves everyone in the dark as to the ownership and control of websites. Predictably, law enforcement is squealing the loudest, once again claiming that all will be lost if they are denied the data they so desperately need to protect us. Of course we need no protection from them.
But truthfully, this renders WHOIS data accessible only to a select few. And that may or may not include
Let's Encrypt supports Certificate Transparency (Score:5, Informative)
All websites with a fully qualified domain name qualify for a domain-validated certificate without charge from Let's Encrypt. Every certificate that Let's Encrypt issues is logged in CT.
Re: (Score:2)
If a CA is not verifying identity then what use is their certificate?
Re:Let's Encrypt supports Certificate Transparency (Score:4, Informative)
Does Let's Encrypt verify identity, I can't find anything on their site about it.
Let's Encrypt is a domain-validating certificate authority, which issues domain-validated certificates. Every such CA verifies that the person requesting a certificate is the same person who controls the domain's DNS. What other sort of "identity" did you have in mind?
If a CA is not verifying identity then what use is their certificate?
If a domain registrar is not verifying identity then what use is their domain?
Re: (Score:3)
Let's Encrypt doesn't issue EV certificates, so no, they don't verify real-world identity. They verify control of the domain name, just like everyone else issuing non-EV certificates. (Put another way, for DV certificates the domain is the identity.) The distinction between DV and EV certificates long predates Let's Encrypt, and their policies regarding domain validation are no more lax than most CAs'. Stricter, actually, since with LE you have to prove that you still control the domain at least once every
Re: (Score:3)
If a CA is not verifying identity then what use is their certificate?
It allows your connection to the web site to be encrypted, preventing ISPs and other nefarious agents from spying on you to a limited extent.
Re: (Score:2)
Does Let's Encrypt verify identity, I can't find anything on their site about it.
If a CA is not verifying identity then what use is their certificate?
What identify are you trying to verify? The identify of the machine in question? That's called Domain Validation, and yes Lets Encrypt does that by requiring that you prove that the certificate being issued for domain x is actually for domain x by showing that the machine actually is in charge of domain x by changing something on domain x during the issuing process.
If you're asking about the identity of the owner of the machine, well that's an Extended Validation certificate and Lets Encrypt doesn't issue t
Re: (Score:2)
Unless Let's Encrypt has changed their policy since I started using them, a certificate has to have an FDQN that's routable on the open internet, and they verify the host(s) are listening on port 443 at least once during the creation or renewal process.
Let's Encrypt won't issue or renew certs for anybody's internal networks, which severely limits its utility.
How to use the dns-01 challenge (Score:2)
Unless Let's Encrypt has changed their policy since I started using them, a certificate has to have an FDQN that's routable on the open internet, and they verify the host(s) are listening on port 443 at least once during the creation or renewal process.
That is true of the http-01 challenge (though the port is 80). But instead of the http-01 challenge, you can use the dns-01 challenge, which requires a FQDN that's routable on the open Internet and listening on port 53. The machine involved need not be on your private network.
Let's Encrypt won't issue or renew certs for anybody's internal networks
Yes it will. Here's the overall procedure to obtain a certificate from Let's Encrypt or another ACME CA using the dns-01 challenge:
1. Buy a domain, preferably from a registrar whose bundled zone hosting has an API supported by an ACME
Re: (Score:3)
Anonymous Coward wrote:
Which is exactly why let's encrypt should have their trust revoked. Such lax policies mean even illegitimate sites can get certificates, just look up all the paypal scammers using let's encrypt to show up as trusted.
By the same reasoning:
Which is exactly why domain name registrars should have their trust revoked. Such lax policies mean even illegitimate sites can get certificates, just look up all the paypal scammers using domain names to show up as trusted.
internal apps / ipmi / other things that are no on (Score:2)
internal apps / ipmi / other things that are not online don't need real certs much less running let's LetsEncrypt with ports open so that runs.
Re: (Score:2)
What doesn't make sense is [appliances on LANs] using https with default certificates just to tick of the "it's secure" checkbox.
That's partly a reaction to browser implementation of Secure Contexts [pineight.com], a W3C spec that reserves certain web APIs for HTTPS sites.
Re: (Score:3)
I think it's more a reaction to browsers popping up security warnings on all non-HTTPS sites [theverge.com].
On the one hand, getting public websites to use HTTPS is almost inarguably a good thing. On the other hand, getting intranets to use HTTPS is nearly useless, and getting mDNS devices to use HTTPS is impossible. That last one is going to be a real problem, and I'm really no
what does this mean for LetsEncrypt? (Score:2)
A lot of people, including myself use LetsEncrypt on a CPanel based hosting account to generate certs for a website.
Are those local, self-signed certificates or something that is registered somewhere? I'd never really paid attention since it just worked and was one less thing to deal with.
Since it's not retroactive there is no problem now, but wondering what will happen when I generate new certs going forward.
If you use LE you're fine (Score:3)
A lot of people, including myself use LetsEncrypt on a CPanel based hosting account to generate certs for a website.
Are those local, self-signed certificates or something that is registered somewhere?
You could answer that question with five seconds on a search engine. Google Search for let's encrypt certificate transparency produces, as its first result, a document [letsencrypt.org] stating the following: "We submit all certificates to Certificate Transparency logs as we issue them."
Re: (Score:2)
Re: (Score:2)
A lot of people, including myself use LetsEncrypt on a CPanel based hosting account to generate certs for a website.
Are those local, self-signed certificates or something that is registered somewhere? I'd never really paid attention since it just worked and was one less thing to deal with.
Since it's not retroactive there is no problem now, but wondering what will happen when I generate new certs going forward.
In this context certificates perform two functions. 1) They provide a key pair which can be used to encrypt the connection, and 2) They provide a way to have confidence that the person / company on the other end of the network is who they say they are. Any certificate (a free self signed or Let's Encrypt certificate, or an expensive certificate from a commercial CA) can be safely used for just encryption. However if you care about validating who is on the other end self-signed certs are worthless, Let's Enc
What does this mean for me? (Score:2)
Re: (Score:2)
It depends on your certificate provider. It may require no changes on your part, if your certificate provider logs them in a CT log. If it doesn't you probably want to switch providers. There's nothing you can do to make up for them not doing it/make them (well, you can complain and see if they're fixing the problem soon enough).
Note, Let's Encrypt (which is free) does
Only new SSL certs need to be in a CT log (Score:2)
This is not retroactive, meaning SSL certificates that were issued prior to May 1, 2018, will continue to work without warnings, even if they are not in a public CT log.
From TFA: The new CT policy is not retroactive. This means that older certs issued before today that have not been recorded in a CT log will continue to work. But if a CA has issued a new SSL cert starting today and has not recorded it in a public CT log, Chrome will show an error.
For those who use self signed certs for whatever reason (I d
Re: (Score:2)
And further, Devon O'Brien, a Google Engineer working on this, posted this back in October 2017 (emphasis mine):
Since January 2015, Chrome has required that Extended Validation (EV) certificates be CT-compliant in order to receive EV status. In April 2018, this requirement will be extended to all newly-issued publicly-trusted certificates - DV, OV, and EV - and certificates failing to comply with this policy will not be recognized as trusted when evaluated by Chrome. Certificates issued from locally-trusted
Corporate CAs? (Score:2)
I don't use chrome but I do some testing with it every once in a while.
All of these security bullshit droppings in chrome is going to cause error fatigue for problems that are either not problems at all or worthless to most users.
All kinds of shit get errors that only appear in chrome. Certs that have a CN but not SAN are flagged only in Chrome for no sane reason.
Well known sites like https://www.kernel.org/ [kernel.org] are flagged as insecure. Again only in chrome.
All resources protected by internal/corporate CA's I
another change (Score:2)
Re:Er, what about LetsEncrypt (Score:5, Insightful)
No, we need warnings for certificates that aren't trusted. Otherwise SSL does nothing to prevent man-in-the-middle attacks.
What would be ideal is to support secure DNS with certificates in the DNS. Then you know you have the right certificate and don't need any certificate authorities at all. Of course, you have to trust the secure DNS. so it's just pushing the trust problem down the road.
Registrars treat DNSSEC as an upsell ($) (Score:3, Informative)
No, we need warnings for certificates that aren't trusted. Otherwise SSL does nothing to prevent man-in-the-middle attacks.
But without a fully qualified domain name, CAs shall not issue a trusted certificate. So we also need a reliable way to provide trustable names for devices on a non-technical users' home network that have a web-based administration interface, such as a modem, router, printer, or NAS.
What would be ideal is to support secure DNS with certificates in the DNS.
I agree that DANE would be ideal. But DANE relies on DNSSEC, which has faced practical problems that hinder adoption. Before about a year and a half ago, DNSSEC's root zone key was too short (1024 bit RSA) for browsers to accept
Re: Registrars treat DNSSEC as an upsell ($) (Score:4, Informative)
Besides, how is a global root CA supposed to verify the connection to a device on a non-routable IP/Subnet?
Secure Contexts (Score:5, Informative)
Why do home devices need to have trusted SSL certs?
Because Service Workers and several other web platform APIs are restricted to secure contexts [mozilla.org] per W3C's spec [github.io]. For example, a browser may restrict the Fullscreen API or Presentation API to secure contexts as a mitigation against phishing by replicating the chrome of the operating system and web browser [feross.org]. In such a browser, the web interface of a NAS on which video is stored will not be able to present the video in the full screen.
Re: (Score:2)
How does "this is absolutely the URL you meant to go to" imply "give them the ability to phish by replicating the OS/browser fullscreen"? FFS, just because I want to make sure I'm getting data from somesite.com, doesn't mean I trust somesite.com to run code/be fullscreen/etc.
Re: (Score:2)
It's in case you saved permission for somesite.com to perform these sensitive operations, so that a malicious actor can't exploit these saved permissions by hijacking somesite.com.
Re: (Score:2)
Ah, it's to verify a whitelist? Cause that's not how JS works (well, it is on my machine, but...)
Re: Secure Contexts (Score:2)
SSL verification ensures the private key of the device, and its domain, matches the public key in the Root CA.
If the key you have doesn't fit the lock, then don't use the whitelist, as its probably not the real door but a trap.
Re: (Score:3)
Besides, how is a global root CA supposed to verify the connection to a device on a non-routable IP/Subnet?
Technically they don't need to. A Domain Validation certificate proves that the certificate holder controls the domain, not the server. Provided you have a (sub)domain you control, you can get a valid DV certificate through a DNS challenge without involving the device at all; the domain's A and/or AAAA records can point to a private or otherwise publicly-unreachable IP address.
This does require a domain name, however, which is extra hassle and expense which most small-network operators shouldn't need to dea
Re: (Score:2)
For the most common cases this could be provided as a service (like DDNS) by the device manufacturer.
In the case of server software installed on a Raspberry Pi single-board computer, who is "the device manufacturer"? Raspberry Pi Foundation? Sony? The publisher of the server software?
Re: (Score:2)
In the case of server software installed on a Raspberry Pi single-board computer, who is "the device manufacturer"?
The person who installed the server software. If you can set up a web server on a Raspberry Pi, you can handle registering and validating your own domain. I did say "the most common cases"—this isn't one of them. The idea is that when someone with little networking experience picks up their Acme Router with an embedded HTTPS administration service, Acme Company provides them with a DDNS subdomain afa7ds9fd.myacme.com, to be printed on the label alongside the default password, and handles the certifica
Re: (Score:2)
Because web traffic can be sniffed, whether on the device or on the network and that compromised network info can lead to harder to eradicate problems. So that's the argument for SSL encryption, at least. Without a cert, how do you know you're even connecting to your own, trusted device?
Besides, how is a global root CA supposed to verify the connection to a device on a non-routable IP/Subnet?
It doesn't need to. For one, home routers act as DNS and can present a real TLD that can be verified. The actual IP address does not matter here.
Re: Registrars treat DNSSEC as an upsell ($) (Score:2)
Perhaps I'm thinking of the issue with SSL certs is that domain wide certs are an extra fee above "A" record specific certs. And A records require an IP, and I wouldn't expect to be able to insert a private class "C" for an "A" record into the DNS records for my domain.
Talking about having a D-Lin
Re: (Score:2)
Certificate authorities are entities that grant certificates. If certs were passed with DNS, a CA would still be needed, even if it's just the DNS server itself.
Of course then the CA could not be airgapped, and the system as a whole would be more interesting to attackers and have a much larger attack surface.
Right now there are warnings for certificates that are not trusted. If they do not have a path to a root of trust there is a warning. If they have been revoked there is a warning. If they are self-signe
Re:Er, what about LetsEncrypt (Score:4, Informative)
This logging system, it does not appear to provide any new services of meaningful value aside from making moderate-knowledgeable people more able to understand a cert and query it's nature.
The point of the Certificate Transparency logging system is to make it extremely difficult for any CAs to get away with quietly issuing extra certificates for your domains to state actors and others to enable them to carry out MitM attacks. Since any CA can issue certificates for any domain, this is a real threat which undermines confidence in the entire CA system; it's only as strong as its weakest link. With browsers enforcing CT logging this attack is no longer possible; the certificates will not be accepted unless they are first made public, and any CA that issued such certificates openly would immediately lose its trusted status and be finished as a CA.
Re:Er, what about LetsEncrypt (Score:4, Informative)
how hard would it be for them to work a command line flag like -gov to not log the certificate they are forging?
Not hard at all, but it doesn't matter since browsers won't accept the certificate if it isn't in the log. That's the point of making CT logging mandatory.
Re:Er, what about LetsEncrypt (Score:5, Insightful)
Sometimes, not protecting against a MITM attack is fine and I don't need to worry about preventing it. Examples include "being on a LAN and accessing something that is required to be behind https by W3C standards" or "local development of secure services before they're uploaded to test".
Re: Er, what about LetsEncrypt (Score:2)
Re: (Score:2)
Re: (Score:2)
I'll admit I don't know the technical specs, but it sounds like a solid solution. I would like to hear if anyone knows if there's a technical reason for not moving forward with it, or if it's just money and politics.
Re: (Score:2)
You don't understand what the certificate is for. It is not the about the half page of data. It is about is the Corporation ABC LTD that is asking for certificate really Corporation ABC. This is because ultimately on the browser side you only see mapping between a certificate and domain name. But the CAs are separate from domain registries, and while domain registries guarantee uniqueness of the domain name, the CAs do not guarantee uniqueness of a certificate.
With Let's Decrypt any compromise of DNS regis
CAA records (Score:3)
IMO all certificates should be EV in the current internet if we want security.
I thought EV certificates were available only to corporations or LLCs, not to individuals. If someone puts up a site to show her personal portfolio, would you prefer to require her to incorporate first?
But the current situation - Let's decrypt being able to issue a DV for any EV issued domain, is completely wrong.
That's what certificate authority authorization (CAA) records [wikipedia.org] are for. If a domain owner publishes a CAA record that doesn't include Let's Encrypt, Let's Encrypt will not issue a certificate for that domain.
Re: (Score:2)
That's what certificate authority authorization (CAA) records are for. If a domain owner publishes a CAA record that doesn't include Let's Encrypt, Let's Encrypt will not issue a certificate for that domain.
How does that work exactly?
If I want a CA to mint me a cert for your domain and I have access to wires over which DNS flows what good is CAA?
Actual use case where CAA is helpful rather than a dangerous feel good checkbox designed to obscure reality is so small you need a microscope to notice it exists at all.
Re: (Score:2)
I have access to wires over which DNS flows
How many routes do you control? Good luck gaining control of all routes belonging to the CA or all routes belonging to both name servers.
Multiple routes, expiry, and CT block that (Score:4, Informative)
CAA records are useless when I hijack the DNS in the first place.
I'm interested to see how you plan to hijack the DNS in a way that evades the following three defenses:
Re: (Score:2)
At what point would you hijack the DNS? A domain-validating certificate authority queries DNS through several Internet routes. How had you planned to hijack them all, especially if the domain's authoritative DNS servers are on different /16s?
Owning insecure wire between name server and Internet.
Certificates issued by Let's Encrypt expire after 90 days, and organizations may renew them at 60, 73, 85, or whatever day intervals. How long do you plan to keep up the DNS hijacking?
Why would I bother with LE when I can get a 3 year cert from a normal CA using exactly the same approach?
If a CA issues an certificate to a hijacker, the domain's rightful owner can check CT logs and find your certificate. The policy change described in the featured article encourages CAs to keep their CT logs complete.
Safe bet they won't.
Re: (Score:2)
Owning insecure wire between name server and Internet.
If you own the only wire between the primary name server and the Internet, the CA will notice that the TXT records on the primary name server do not notice the TXT records on the secondary name server.
Why would I bother with LE when I can get a 3 year cert from a normal CA using exactly the same approach?
Not needing to whip out your credit card for every hostname that you control.
The policy change described in the featured article encourages CAs to keep their CT logs complete.
Safe bet they won't.
If CAs don't use CT, then as described in the featured article, users of Google Chrome will not be able to use HTTPS on websites using certificates from those CAs, causing web server administrators to seek refunds from said CAs. Is pr
Re: (Score:2)
IMO all certificates should be EV in the current internet if we want security.
Every house should be made of solid steel and have no windows either. But total security is impractical and also quite pointless. I don't care about some random hacker taking over all of Slashdot via a sophisticated attack in order to read some user comments. That doesn't however mean I want to blast those comments back and forth across the airwaves in plain text at an internet cafe.
There are solutions in between Fort Knox and having a house made entirely of paper, and there are needs for those solutions to
Re: (Score:2)
You don't understand what the certificate is for. It is not the about the half page of data. It is about is the Corporation ABC LTD that is asking for certificate really Corporation ABC.
Really? I thought it was for encrypting passwords to networking devices so they were not sent in clear text. At least that is what i use them for most of the time. And my self signed certs send my browser into fits of impropriety!
Re: (Score:2)
Nope. Keys are for encryption. Keys wrapped and bound to identity are called certificate. Gutting what the certificate meant, just to get to keys, is extremely stupid.
Re:Er, what about LetsEncrypt (Score:4, Interesting)
Perhaps, on the other hand, without letsencrypt most of us would not have websites. The poor people of the world would be completely cut off from having their own website, that was not the dream of the internet.
We cannot be putting restrictions that cut off chunks of the population because they do not meet our criteria, the internet and having your own website should be free and open to all.
In the bad old days you could only get an SSL certificate if you were incorporated, provided your contact phone number, real name, address, and pay a hefty sum of money. This was completely unacceptable and went entirely against the whole point of the internet. With letsencrypt the playing field has been leveled and this is a good thing and it is keeping the internet operational in the hands of the people.
Honestly though I am still of the opinion that we should completely eradicate centralized certificate authorities. The certificates should be there to provide encryption which they do whether they come from an authority or not. We should allow free self signed certificates with no warnings. I should not have to link myself up to some 3rd party of any kind to operate my website.
Self-signed certs don't block first-visit MITM (Score:2, Insightful)
We should allow free self signed certificates with no warnings. I should not have to link myself up to some 3rd party of any kind to operate my website.
Under your proposal, what distinguishes the self-signed certificate that you generated for your domain from the self-signed certificate that the operator of an intercepting proxy (a "man in the middle") generated for your domain, particularly on a client's first visit?
Re: (Score:3)
Nor do self-signed certs block DNS MITM (Score:2)
Using a DNS entry as a root of trust will work once DNSSEC support becomes a standard feature in the zone hosting that major domain name registrars bundle with registration. Until that comes to pass, anyone with power to spoof DNS can also spoof your certificate.
Re: (Score:3)
Just to get a ballpark figure to guide further discussion of your opinion on Let's Encrypt: How much do you think someone ought to have to pay per year in order to host a personal portfolio site?
Passwords and Secure Contexts (Score:2)
And [a personal portfolio site] doesn't need to be encrypted
Let's say a web developer's portfolio site contains demonstrations of web applications, and the users of these web application can create accounts. Without encryption, how should the web developer protect the passwords and session tokens of the users of the web application from interception when exhibiting this application to the public?
Let's say a web developer's portfolio site contains demonstrations of web applications, one of which uses Service Workers or another web API that has been restricted to secu [github.io]
Re: (Score:3)
Like a standard cert from someone else requires anything beyond rudimentary photochop skills?
Pinning would do a LOT more for security than the CAs ever have, but since that doesn't present any exciting new business opportunities, it remains unimplemented.
Re: (Score:2)
LetsEncrypt is literally the worst thing to happen to Security on the internet. Its theater and its dangerous.
Oh? Please expand on your reasoning. What makes Lets Encrypt any worse than any other DV issuer? When you're done answering I'll tell you why they are a damn sight better than most.
Re: (Score:2)
Let me try to rephrase how I understood DarkOx's comment:
Issuing TLS certificates based on domain validation, not organization validation, is literally the worst thing to happen to security on the internet. It's theater and it's dangerous.
Re: (Score:2)
But like DarkOx I am asking you to explain your reasoning. DV certificates identify the machine on the other end for the purposes of creating an encrypted channel. So explain why its so bad?
Is SSH nothing more than security theater and we should all either fork out $600 for EV certificates on our servers or just settle with Telnet as well?
Typically the people who say DVs are theater are those who don't understand the purpose of DVs.
DV doesn't protect against typosquatting (Score:2)
DV certificates identify the machine on the other end for the purposes of creating an encrypted channel. So explain why its so bad?
Consider this: bankofarnerica.com has an "RN" in it, but it's hard for especially non-technical users to see. Homoglyphs like this can be and have been used in phishing attacks. Under domain validation, what prevents widespread typosquatting the way organization validation can?
Re: (Score:2)
Nothing, which is also why DV and OV are treated differently. It's why I see "Bank of America Corporation [US]" in the heading of my browser. If I just saw the word secure it would be telling me something different.
Since we're playing the consider this game:
Do you live in a house with no door locks or window latches?
If not do you live in Fort Knox?
The world is not based on extremes but rather sliding scales. DV certificates serve exclusively the purpose of encryption which is a layer of protection, kind of
Re: (Score:2)
How is an end user supposed to know where on the sliding scale a particular site is supposed to sit?
Re: (Score:2)
Risk lies with the end user as the end user's usage and ONLY the end user's usage defines the risk. We are posting here on Slashdot. A site that regularly criticises governments and political parties. I am in a western country with reasonable levels of speech protection. My risk is low. What if I were in China or Iraq, or India where Slashdot was recently blocked? There I would have a different risk profile.
Defining your risk is not something you can outsource to someone else.
Making everything have the high
Re:Er, what about LetsEncrypt (Score:4, Informative)
In answer to your subject, from https://letsencrypt.org/certif... [letsencrypt.org]:
So LetsEncrypt certs will work fine with Chrome.
Re: (Score:2)
Re: Er, what about LetsEncrypt (Score:2)
Re: (Score:2)
Maybe you should do it now. Please. And make sure you change your settings so you can't override and then accept an untrusted certificate
Come post on your reply here on Slashdot when you're done.
Re: (Score:2)
Good catch as I didn't know slashdot.org actually use Let's Encrypt SSL service. Figured it's a commercial website would use something like GoDaddy to provide high level of trust.
Re: (Score:2)
Figured it's a commercial website would use something like GoDaddy to provide high level of trust.
Are you aiming for a +5 Funny? Because That's how you get a +5 Funny. I hope mods are watching :)
Re: (Score:2)
something like GoDaddy to provide high level of trust
I turned my head just in time. So now I have a mess to wipe up, but don't need a new keyboard. It was a near thing.
Re: (Score:3)
Let's Encrypt certificates are issued under an intermediate that has always been cross-signed by IdenTrust, an older and more established CA.
Re: (Score:2)
If you're a betting man let's make a bet. I could do with some very easy money.
Cool I win. I see the green "Secure" symbol at the top of the screen. Oh wait you didn't realise Slashdot has a DV certificate from Lets Encrypt did you... You're funny.
Re: (Score:2)
Just having your data "encrypted" is not good enough...
You need to ensure that not only is your data encrypted, but that only the intended recipient has the decryption key. That's where certificates come in, to verify the remote peer.
Without certificates or some form of pre shared keys, anyone can sit in the middle and establish an encrypted connection to you, then create a separate encrypted connection to the target you were intending to connect to and watch all the traffic as it gets decrypted by the atta
Re: (Score:3)
If they did care about the end user's security, they wouldn't make stupid changes like not trusting end-user / admin installed CA certs by default.
Chrome opts in through its network security config file [googlesource.com], and Firefox has its own TLS engine. So this affects mostly native apps that use Android's TLS engine.
Since when does removing / forbidding the user's input on trust somehow boost their security?!?!?
Malware has in the past added certificates as a means of intercepting apps' traffic. So have governments.
Re: (Score:2)
When you say this affects native apps that use Android's TLS engine... well, how does that help the enterprise which has users using Android devices?
I don't see how your response helps sites that use an internal CA, which is a perfectly legitimate activity.
There are all kinds of places where it's completely unnecessary to pay extortion for a global certificate, yet it's mandatory to have encryption (and mutual validation) to protect sensitive traffic flying around on the corporate WAN. Enterprises also have
Re: (Score:2)
how does that help the enterprise which has users using Android devices?
I don't see how your response helps sites that use an internal CA, which is a perfectly legitimate activity.
If they're websites, they'd be viewed using either Chrome, whose network security config allows use of user-installed certificates, or Firefox, which has its own TLS engine that also allows use of user-installed certificates. If they're not "sites" but native apps distributed as free software that access an internal HTTPS server's REST API, then the business can download each application's source code from the repository linked on F-Droid and rebuild the APK with a network security config referring to a pin
Re: (Score:2)
And if they’re apps that are not open source, and it accesses the internal HTTPS server’s REST API (with an internal CA Certificate)?
For example, an enterprise install of HipChat, with users using Atlassian’s HipChat for Andoid?
It sounds like the App will be broken, and users will have to use the web interface (and not get things like notifications).
Re: (Score:2)
And if they’re apps that are not open source
Develop, or fund the development of, a free replacement for said non-free app. Or file a support ticket with the application's publisher to whitelist your company's internal server's certificate in a customized build of the application for your company.
Re: (Score:2)
In other words, a giant "F U" to enterprises that use internal CA's: Google is breaking working applications, and giving no solution that doesn't cost a significant investment of time and effort.
Got it.