Starting Today, Google Chrome Will Show Warnings for Non-Logged SSL Certificates (bleepingcomputer.com)

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.

Comments

this is starting to feel like email

[cascadingstylesheet]

You'll need an SPF record ... oh, and DKIM ... oh yeah, and DMARC ...

Re:this is starting to feel like email

[Anonymous Coward]

We can't have crypto be unregulated now can we?

Re:this is starting to feel like email

[Anonymous Coward]

Gotta keep throwing up those barriers to entry. Can't have the small fry getting in on Google's take, now can we?

Re:this is starting to feel like email

[Anonymous Coward]

Sure just use web of trust, I've heard rumors that it actually worked once for someone.

Re:this is starting to feel like email

[Anonymous Coward]

SPF/DMARC/DKIM are quite essential. really the three should have been rolled into one implement.

Their to provide to the world who can send email from your domain(s) and authenticate your senders to the world.

its pretty fricken simple to set these up.

The problem is their three specifciations, thrown tot he world rather ad-hock across different time-frames. Often lacking in crucial setup guidance.

.

----
Do you recall an email world before gmail service?
*SO MUCH SPAM*

everyone else had to play catchup to get on-game with gmail. but if DKIM / SPF / DMARC were around an mandatory in 2000.... spam wouldn't be nearly an issue it is now -- which requires blacklists, bayesian filters, content fileers, and more.

its the filter that are the insanity, along with email campaign companies like emma/constant contact which often recommend incorrect setups of SPF. (seriously, the only option for ending SPF is with -all anything else is incorrect and allow spam).

Re: this is starting to feel like email

[Anonymous Coward]

No, those solutions simply encourage spammers to crack systems and send email through them, which actually happens a lot already.

Re:this is starting to feel like email

[Anonymous Coward]

The problem is that you think "their" means "they're"

Re:this is starting to feel like email

[Anonymous Coward]

it's always like that, you just start small and then slowly increase if someone cry's, do it for the children but then i don't use that spyware software from nsa brother

Re:this is starting to feel like email

[Anonymous Coward]

Good thing it only takes about 15 minutes to set those up!

Of course, you could have someone highly experienced and competent set up your mailserver, instead of an unpaid intern. Then it'd be much quicker.

Another Google metadata sink?

[Anonymous Coward]

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?

Re:Another Google metadata sink?

[Anonymous Coward]

Google Chrome is the shittiest web browser ever.

Re:Another Google metadata sink?

[Anonymous Coward]

I can hear you was born after IE 6.

Re:Another Google metadata sink?

[squiggleslash]

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.

Re:Another Google metadata sink?

[houstonbofh]

I am ready to break all cert warnings entirely. As a networking professional logging into self signed certs all day, the cure is FAR worse then the disease!

Re:Another Google metadata sink?

[Curunir_wolf]

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?

[Bert64]

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?

[Anonymous Coward]

No I were NOT!

You is stupid and you're use of language are lacking!

Re:Another Google metadata sink?

[Anonymous Coward]

That wouldn't fix what Google is proposing here. Any corporate CA would, most likely, not be registered in a CT Log. This is bullshit and an attempt for Google to enforce unneeded requirements on the WWW.

Re: Another Google metadata sink?

[jabuzz]

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:Another Google metadata sink?

[caseih]

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?

[Junta]

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: Another Google metadata sink?

[Junta]

http://www.chromium.org/admini...

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)

Re:Another Google metadata sink?

[Anonymous Coward]

if someone was able to MITM you they could steal some powerful credentials.

Ha ha, that's cute. Our company IS the man in the middle. All traffic goes through websense which requires an internal company trust CA installed in every browser specifically so ALL https traffic can be decrypted and scanned live.

You appear to be naively un-aware of how enterprises really work. You also appear to be naively un-aware how enterprise class servers are managed by vendor provided interfaces that use all manor of certs, both proper and broken, burned into firmware which neither of us can change. Web browsers that accept broken certs are necessary tools to do our job.

You're looking pretty delicate in your glass house up there on the hill.

Re:Another Google metadata sink?

[Anonymous Coward]

self signet certs are actually the only trusted certs you could actually trust, saying that you need to be the one creating them in the first place, any other cert is just a smoke screen for security

Re:Another Google metadata sink?

[Junta]

One amendment, that CT policy is better than I presumed it would be:
http://www.chromium.org/admini...

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 teams do internal IT.

Re:Another Google metadata sink?

[Junta]

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:Another Google metadata sink?

[Anonymous Coward]

creimer, I reported you to youtube and amazon and I keep and keep reporting every spam post you make so all these spam posts will do is bring your view count in negative territory for a given day since youtube barred your stupid click-bot and your spam posts.

MODDOWN! ; creimer spam post again!

creimer wants you to click on his youtube channel, then click on his stupid amazon affiliate link spam on Youtube. There is nothing of value on creimer youtube channel. Only creimer click-bot goes there.

Re:Another Google metadata sink?

[Anonymous Coward]

I'm confused what point you are trying to argue, since you argue for both sides equally.

You initially state:

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.

But you then contradict that claim with the statement:

In my mind for internal servers and devices, my own certificate authority is far more secure than using something like Let's Encrypt.

Self-signed certs are certainly equally as secure as using your own certificate authority, but using self-signed certs is a major hassle, a huge workload, all falls apart if not done perfectly correctly each and every time, and isn't best practice.

Using your own certificate authority however solves nearly all of those problems, and is best practice.
Not to mention it will solve the problem the original poster made regarding certs at work using Chrome, while self-signed will not.

Self-signed is so much worse to deal with than a personal CA, the work involved alone makes it a "less good" option.

For example, did you check each and every last certificate thumbprint digit before trusting it? How do you update/revoke one over all your client software/systems?
Do you have an authoritative listing of thumbprints for others?

All of those problems multiply the more certs you have and the more people/browsers you need to keep them in sync with.
This is why a personal CA is far better, and this latest change is just one more reason.

Don't self-sign certs, sign them with your own CA private key!

Then you have only one public CA key to validate, once per device, and it handles the trust chain for all of your other internal certs.
It's basically doing the same thing you have done hundreds of times, but you do it once. Far less opportunity to fuck it up by approving a cert that isn't yours but the first and last few digits in the thumbprint happened to match.

It also has the added benefit that non-geeks can actually utilize this option.
It's been proven beyond all doubt that normal users will accept whatever without bothering to check even once, let alone the hundreds to thousands of times you are asking them to do so.
After the first couple of times they will just ignore anything you say and accept trusting a cert blindly, which at some point may end up not being your actual self-signed cert!
Ask them to do it once, say it only needs done once every decade, and they are FAR more likely to actually verify a CA public key properly before trusting it.

Re:Another Google metadata sink?

[Anonymous Coward]

For the love of god, someone please tell me what security we are buying by encrypting traffic between admin workstations and datacenter servers.

If there was a real attack vector there, we'd be fixing it at the network layer. Seriously, what the flying F*CK are we doing with application layer encryption on a trusted network? There is no possible way to sufficiently secure IP and DNS on a trusted network? Give me a break. I'm so tired of "good" ciphers constantly changing, browser warnings, certificates expiring and all the bullshit that does NOTHING for security on a trusted network. All they do is generate work, and clog network vulnerability scans.

Re:Another Google metadata sink?

[Anonymous Coward]

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.

SSL use in IT shops is at cargo cult levels. People are just checking "enable encryption" with no thought towards why.

Step 1. Stop reflexively enabling SSL on trusted networks.
Step 2. Network security scans come back without "SSL vulnerabilities", corporate MITM devices, taps, IDS, proxies etc. start working better, LIKE MAGIC.
Step 3. Use time saved in step 2 to monitor network for actual threats.

If IP or DNS can be compromised on your internal network, WTF does anything else even matter. It makes absolutely no sense that encrypted network data outnumbers encrypted data at rest. If it's not needed for authenticity, and not needed for privacy, then WTF are we "enabling encryption" for?

Re:Another Google metadata sink?

[Anonymous Coward]

Or simply it's just stupid language.

Re:Another Google metadata sink?

[Junta]

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 management isn't particularly onerous, despite offering the same sort of security benefits as TLS. People will complain that first contact between a given ssh client and ssh server pair is rarely ever secured, but as far as compromises go, it isn't so shabby. Additionally, SSH in practice has a number of facilities for the willing to do some sort of relevant PKI to mitigate that concern.

Structurally, the use of certificates in TLS can enable a superset of the way SSH keys can be managed. The private/public keypairs are there as it is in SSH, but with facilities to allow third party trust relationships too. The problem is the state of applications, libraries, and best practices end up making people blindly accepting connection every time or installing very broad CA certificates. I've even heard of one place signing a wildcard certificate and passing the related private key around everywhere so they wouldn't have to 'fool with it' and just have every device have the exact same keypair. TLS is frustrating because of these limitations *in practice*, but I'd rather see a better usage model for the key management than to ditch the concept entirely.

Re:Another Google metadata sink?

[Bert64]

Defense in depth...
Hackers are opportunistic, you can do almost everything right but make one tiny mistake at the wrong time and your toast.
Having multiple layers of defense can mitigate against mistakes, and also against zero-day vulnerabilities in certain components.

A defender has to cover everything, an attacker only needs to find and exploit one weakness.

Er, what about LetsEncrypt

[Anonymous Coward]

While most SSL certificates are nothing but a 1/2 page file of random text they can cost upwards of 600$. I've been utilizing LetsEncrypt because...honestly your system can create these certs for free, having them being sold is beyond stupid for a file that isn't even as big as a happy face jpg.

No one really wanted centralized paid certificate authorities in the first place. Lets encrypt rose out of the backlash from people like me who thought the whole thing with paying money for something so small was beyond stupid and having all these browser warnings about it etc was also equally stupid.

What should the solution be? NO WARNINGS! That way we do not need lets encrypt or anyone else, if the site has an SSL certificate than it is encrypted and that should be the end of the story, where the cert came from who verified it who it is registered to make no difference what so ever the only thing that matters is that your communication is encrypted. The warnings they put up make it seem like if I didn't go with letsencrypt and just used a self signed certificate that I am out to steal money or perform some other criminal nefarious act and this is absolutely bull. Regardless of wether an SSL certificate is from an authority or self signed the data flowing between client and server is encrypted.

I get leary when I hear they are going to make the warnings etc even worse when they already go too far in my opinion and make people alarmed and scared over absolutely nothing. Encrypted traffic is encrypted traffic and that is that. There is no need for any 3rd party doing 'verification' of any kind because verification does not create the encryption, verification does not enhance encryption, verification does nothing.

Re:Er, what about LetsEncrypt

[crow]

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.

Re:Er, what about LetsEncrypt

[I4ko]

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 registration, routing or similar can result in legitimately looking certificate being issued to an illegitimate actor. Having both EV and DV does not work, or rather, in order to know if there is an EV cert, while you are seeing DV served to you, you need another system - this is where CT comes into play.
IMO all certificates should be EV in the current internet if we want security.
All certificates being DV (and no EV at all) is also feasible is we don't have CAs as separate entries from domain registries.
But the current situation - Let's decrypt being able to issue a DV for any EV issued domain, is completely wrong.

Re:Er, what about LetsEncrypt

[Anonymous Coward]

No, we need warnings for certificates that aren't trusted

Isn't this the current system in place? I happen to receive a warning, with an option to 'get back to safety' or override. What would replace this, then?

Re:Er, what about LetsEncrypt

[swillden]

In answer to your subject, from https://letsencrypt.org/certif...:

We are dedicated to transparency in our operations and in the certificates we issue. We submit all certificates to Certificate Transparency logs as we issue them. You can view all issued Let’s Encrypt certificates via these links:...

So LetsEncrypt certs will work fine with Chrome.

Re:Er, what about LetsEncrypt

[hispeedzintarwebz]

Ctrl-F "letsencrypt" Worries eased.

Re:Er, what about LetsEncrypt

[Anonymous Coward]

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-signed there is a warning.

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. Sounds good but who decides what constitutes a threat? The cert logging policy website indicates CA certificates are strange. They are not. They are mandatory for trust. Apparently the people who made this logging feature get to decide what is and is not a concern to the rest of us, without accepting the fundamental nature of PKI as being strange.

Re: Er, what about LetsEncrypt

[Monster_user]

I think the parent of your comment was saying we need the current system. Given that the GP's goals are pure fantasy.

Re: Er, what about LetsEncrypt

[Monster_user]

Great, another thing to add to my checklist. All "letsencrypt" root CA certs must be checked for and removed, if present, before logging onto an SSL site.

Re:Er, what about LetsEncrypt

[Anonymous Coward]

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.

Re:Er, what about LetsEncrypt

[tepples]

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?

Re:Er, what about LetsEncrypt

[tepples]

Let's Encrypt certificates are issued under an intermediate that has always been cross-signed by IdenTrust, an older and more established CA.

Re:Er, what about LetsEncrypt

[sjames]

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:Er, what about LetsEncrypt

[thegarbz]

While most SSL certificates are nothing but a 1/2 page file of random text they can cost upwards of 600$. I've been utilizing LetsEncrypt because...honestly I'm too dumb to understand the difference between a DV certificate and an EV certificate, and I believe that certificates should be priced according to the number of bytes in a text file because I don't even know how to computer.

FTFY. Was I right? I got it right didn't I.

By the way, Lets Encrypt rose out of the idea of automating checks, not out of the ashes of stupidity. That is user stupidity, or rather stupidity of people like you.

Re:Er, what about LetsEncrypt

[Anonymous Coward]

You already rely on DNS for certificate authenticity, because almost all certificates are issued based on domain verification only, and that's without DNSSEC. Public keys in DNS combined with DNSSEC would be a big boost to security.

Re:Er, what about LetsEncrypt

[Anonymous Coward]

You're not thinking this through. The DNS server does not need to issue anything. It just needs to tell the client that the server will present a certificate with a particular public key. Then it doesn't matter who issued the certificate. It just needs to match the public key and could even be self-signed. You have to trust DNS, but you already do because certificates are almost always issued based on domain-verification only these days.

Re:Er, what about LetsEncrypt

[thegarbz]

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 too.

Re:Er, what about LetsEncrypt

[thegarbz]

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:Er, what about LetsEncrypt

[thegarbz]

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: Er, what about LetsEncrypt

[thegarbz]

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:Er, what about LetsEncrypt

[tepples]

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: Er, what about LetsEncrypt

[Anonymous Coward]

$35/year sound alright for hosting. And it doesnâ(TM)t need to be encrypted

Re: Er, what about LetsEncrypt

[houstonbofh]

But I understand the GGPs frustration. As a networking consultant, I am having to clickthough self signed certs all day. If there was a good browser that I could globally allow self signed certs, I would switch in a heartbeat! The cure is worse then the disease for me.

Re:Er, what about LetsEncrypt

[houstonbofh]

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:Er, what about LetsEncrypt

[thegarbz]

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.

Re:Er, what about LetsEncrypt

[Anonymous Coward]

This is an idiotic viewpoint and you should feel stupid for saying it.

Re:Er, what about LetsEncrypt

[JesseMcDonald]

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

[Curunir_wolf]

A better idea would be to use blockchain as the trusted authority. It's decentralized, consensus-based, and simpler to implement than installing "trusted CA" certs all over the place.

Re:Er, what about LetsEncrypt

[Anonymous Coward]

how hard would it be for them to work a command line flag like -gov to not log the certificate they are forging?

Re:Er, what about LetsEncrypt

[Actually, I do RTFA]

No, we need warnings for certificates that aren't trusted. Otherwise SSL does nothing to prevent man-in-the-middle attacks.

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

[Bert64]

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 attacker's machine and then re-encrypted for onward transmission.

Re:Er, what about LetsEncrypt

[Actually, I do RTFA]

Perhaps, on the other hand, without letsencrypt most of us would not have websites.

Well, would not have encrypted connections to our websites... which Google is trying to make the same thing as not having a website. But I've had an unencrypted website for years. Mighty hackers, see my resume on route to other people!

Re:Er, what about LetsEncrypt

[JesseMcDonald]

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

[I4ko]

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

[Anonymous Coward]

Perhaps, on the other hand, without letsencrypt most of us would not have websites.

You would have a website, but you wouldn't have a website that uses ssl.

You can buy a real Comodo certificate from www.ssls.com for $5 USD per year, I don't consider that to be onerous. They've had that price for many years, long before letsencrypt became popular.

Actually, now that I check www.ssls.com, the price has dropped to $3.88 USD for their cheapest certificate.

Re: Er, what about LetsEncrypt

[Anonymous Coward]

The cure just makes insecure kludges really annoying.

Re:Er, what about LetsEncrypt

[Anonymous Coward]

Wow, you got modded insightful by some dumbass that doesn't even know what TLS is. It doesn't matter one shit if your session traffic is encrypted if you're communicating with the WRONG person. Dipshit.

Re: Er, what about LetsEncrypt

[Darkk]

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: Er, what about LetsEncrypt

[thegarbz]

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:Er, what about LetsEncrypt

[crow]

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: Er, what about LetsEncrypt

[swillden]

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:Er, what about LetsEncrypt

[Anonymous Coward]

"leery"

Re: Er, what about LetsEncrypt

[Anonymous Coward]

Your mother and I are so proud of you, son. We raised you to be an arrogant shitbag and you never fail to please us.

Re:Er, what about LetsEncrypt

[Anonymous Coward]

To which any authoritarian state would simply say to the browser makers: "Either whitelist this or you won't like what visits you next." Best part: It only takes one, and your entire trust is still compromised. I'll give the Five Eyes about a week to get the proper signatures in order. A sudden disappearance or two maybe a few unexplained sick days / family emergencies and the browser makers will come around.

Re: Er, what about LetsEncrypt

[Monster_user]

Misunderstood. Never heard of LetsEncrypt before, and it sounded, from the parent of the post I replied to, like LetsEncrypt was not verifying against actual public domains. Ie. Essentially blindly trusting all self-signed certs rendering the purpose of a Root CA ineffective. Given that another verification methodology was mentioned, and most of the context here seemed to be pushing LetsEncrypt for home devices and such, which would not normally be matched with public registered domains, I misunderstood.

In reviewing the certificate chain for Slashdot, Let's Encrypt is an intermediate authority, and not a root CA.

I will step back and reassess the situation with the appropriate information.

Re: Er, what about LetsEncrypt

[thegarbz]

Yeah I can provide you a bit of information. Lets Encrypt is a project that provides free SSL DV certificates. It's a CA that is cross signed by IdenTrust (giving it support in all usual systems), but also has it's own root which isn't widely used.

A lot of the flack Lets Encrypt gets comes from a few silly misconceptions:

1) They are free. Free means no people involved. Therefore it must be bad because where is the trust right?
2) They only issue DVs. CAs that only issue DVs can't be trusted because they aren't doing all the necessary checks right?
3) I was able to get a DV without sending through my passport or other ID, therefore they aren't doing the checks right?
4) Lets Encrypt gives you certificates in seconds, so it can't be through right?

All three of those basically come down to a misconception of what DV proves: That a machine actually controls content on a domain. Nothing more. Lets Encrypt achieves this free of charge through automated scripting. If you want a certificate for you host, the script works with the Lets Encrypt API through a challenge and response type exercise proving that the host the script is running on is able to modify a specific file in a specific folder associated with the domain that is having the DV issued. The certificates are only valid for 3 months at a time.

They do something similar with a wildcard certificate but rather than modifying just a file being served up by the host it also needs to modify a DNS record to prove the machine controls the entire domain.

Some people say that without humans in the process it's not a good verification. I say that because there are no humans in the process it's not a good verification.

Though one legitimate criticism is that this process is vulnerable to hacking in that if you can take control of routing you can pretend to be the domain owner for the purposes of fraudulently obtaining a certificate. My response to that is that DV certificates are like the door lock to your house and not a bank vault. Just like your house is susceptible to a brick through the window doesn't mean door locks don't serve a purpose, and if you have a bank vault maybe a DV certificate is not for you.

Transparency doesn't mean what you think it means

[Anonymous Coward]

Why in the FUCK would I register an SSL cert with Google? What kind of extortion crap is this?

This is of course on top of a rather quiet HTTP Header that was introduced in October which these same browsers are honoring. It tells the browser to report SSL cert usage and doesn't appear to have any way to be turned off. I only found it by looking at Discord.

My network. My browser. My choice. GTFO. Think it's long over due for certain tech companies in Silicon Valley to be labeled terrorist organizations.

So....F U Proxies and Internal CAs.

[Anonymous Coward]

This policy of users trump device owners is BS. I'm surprised Google just hasn't mandated that all sites must be signed by their CA to be included in their search results and to work in Chrome / Android.

Their engineers care only about one thing: Making sure that the data Google receives is track-able and sell-able to advertisers. They could care less about the end user's security. 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. Since when does removing / forbidding the user's input on trust somehow boost their security?!?!?

Nevermind the fact that most won't even know what the log represents or how to interpret it, but with the big flashy graphics and error messages, IT departments everywhere will be getting complaints, and further questions of "are you snooping on me?" even if they aren't, or if they are snooping, they'll get burned at the stake without the idiots realizing "If you want privacy, don't involve others, including their devices." It's simple. Do your banking / shopping / porn surfing at home if you don't want your boss finding out about it. If you do it at work, then you have no right to complain when they find out about it.

Re:So....F U Proxies and Internal CAs.

[tepples]

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, 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:So....F U Proxies and Internal CAs.

[Anonymous Coward]

Thing is SSL's no better even WITH their changes. If you're the target of some three letter agency, do you seriously think installing a bugged browser is any more difficult then some SSL CA? An employer will likely push out the change automatically anyway so now in both cases you added to the mountain of bullshit being passed around as security.

Remember kids, at one point mixed domain content DID alert, by default. If you went to a site using SSL that had some resource which wasn't, guess what? The browser would complain. It was removed because I believe Mozilla thought it confused users.

That doesn't even TOUCH the surface of their little racket. How many of you still have tcp fast open enabled? It is basically a side channel attack, using SYN packets to exfiltrate data. Whereas hosts should be dropping such packets, they actually managed to convince the world that such checks be disabled to facilitate their cookie data. Well that's just great sparky, what about other data? Thanks Google.

Re:So....F U Proxies and Internal CAs.

[sl3xd]

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 the right to keep their internal CA's certificates off the open internet -- where does it make sense to provide Google with every hostname in your WAN? What right do they have to the information? They have none..

Preventing an enterprise from implementing sane, industry-accepted practices is asinine. Admins have every right to install and set trust for internal certificate authorities.

If anything, I fault Google (and other browser makers) for hiding certificate information - all a user gets without having to go into developer mode is a green padlock and "secure".

Re:So....F U Proxies and Internal CAs.

[tepples]

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 pinned copy of the internal certificate.

Re:So....F U Proxies and Internal CAs.

[sl3xd]

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:So....F U Proxies and Internal CAs.

[tepples]

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:So....F U Proxies and Internal CAs.

[Anonymous Coward]

Or make an android fork and fix the bug in the OS, and rebase the patch as needed against upstream.

Here's hoping things like LineageOS will fix this issue, as few groups even corporations have the resources to burn recompiling fcsking everything just to make things work. Otherwise we're going to need to take some google devs outback for an "educational" session about why removing trust is a bad thing to get this "fix" removed.

Re:So....F U Proxies and Internal CAs.

[sl3xd]

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.

Registrars treat DNSSEC as an upsell ($)

[tepples]

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 as part of a certificate chain. And many domain name registrars bundle zone hosting with a domain, but a lot of these (such as GoDaddy) have charged more for zone hosting with DNSSEC than for zone hosting without DNSSEC.

Re: Registrars treat DNSSEC as an upsell ($)

[Monster_user]

Why do home devices need to have trusted SSL certs? They are not web facing, and if they have remote capabilities they are typically routed through a service provided by the manufacturer. There is no reason to go through the trouble of key generation and registration against a global root CA.

Besides, how is a global root CA supposed to verify the connection to a device on a non-routable IP/Subnet?

Re: Registrars treat DNSSEC as an upsell ($)

[JesseMcDonald]

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 deal with. For the most common cases this could be provided as a service (like DDNS) by the device manufacturer. However, my proposal would be to bypass the CAs altogether: If the first part of the domain is the base-32 encoding of the fingerprint of the certificate (which may be self-signed) then browsers should automatically consider the certificate Domain Validated. The domain name itself identifies a particular certificate—what more evidence is needed? The "fingerprint domains" will be long, of course, but the initial discovery can be handled via an HTTP redirect or mDNS. Afterward, assuming the user bookmarked the full domain name, they can be sure they're connecting to the same device (trust-on-first-use).

Re: Registrars treat DNSSEC as an upsell ($)

[tepples]

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: Registrars treat DNSSEC as an upsell ($)

[omnichad]

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 ($)

[JesseMcDonald]

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 certificate signing process for them.

Is the domain validation process a hassle for those assembling their own servers? Sure, which is why I suggested an alternative protocol for LAN devices. But it's hardly an insurmountable obstacle, provided the device has an official domain name to validate.

Re: Registrars treat DNSSEC as an upsell ($)

[Monster_user]

I'm all for the cert, but I see no benefit in having a third party authentication mechanism just to eliminate some browser warnings. Verfiy the cert, and save it locally to the machine/browser as an exception.

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-Link or Netgear or Linksys, or Belkin router provide a TLD for itself, that is a bit more than I ever would have considered for a consumer appliance.

What would that be, a Belkin.Route TLD, with an SSL cert which matches all Belkin routers? How would the cert be protected from maliscious actors? Once the device is physically in the hands of an untrusted party, everything on it should be assumed to be compromised? And the device would have to have a private key stored locally on the device itself to match the public key for the TLD. Which could then be ported to other devices for man-in-the-middle attacks.

Otherwise how would one manage per person TLDs? Each TLD would require an admin. That admin may well manage multiple sites. Those sites could be single occupant/user sites. Or the admin's home and a secondary site. More importantly who would want to manage consumer devices? If one really had need of validated certs, one could learn, or hire somebody, to implement a system and configure the certs,

Re: Registrars treat DNSSEC as an upsell ($)

[omnichad]

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.

Certs are issued by hostname without regard to what they resolve to (or whether it's an A record or CNAME). And it doesn't matter, because the router can intercept DNS requests and replace its local IP anyway.

For Netgear, you visit http://www.routerlogin.net/ or http://www.routerlogin.com/ to log into the router. They only need one SSL certificate and no matter how many routers are involved, or how many different IP addresses are involved, the biggest concern is that the firmware doesn't auto-update before the certificate expires. I don't know how they handle the private key, but it could be stored elsewhere than the flash and it may be hard to get at if you aren't able to get flashed firmware to boot.

Scam

[rickb928]

This seems more and more like an effort to compel website owner/operators to buy into the SSL certificate scheme.

Revenue.

Re:Scam

[Anonymous Coward]

You know you can get a ssl cert for free and have it configured in like 30 seconds with certbot, right?

Re:Scam

[rickb928]

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:Scam

[Anonymous Coward]

This is an attack on your freedom and a method to control who is permitted to run a website.

Re:Scam

[rickb928]

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 law enforcement, governments, intelligence communities, and the unnamed that will circumvent GDPR without a second thought or any real opposition.

The Web is not well thought of by many who desire power and control.

internal apps / ipmi / other things that are no on

[Joe_Dragon]

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.

what does this mean for LetsEncrypt?

[PhantomHarlock]

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.

Re:what does this mean for LetsEncrypt?

[Anonymous Coward]

Certificates from Let's Encrypt are neither local, nor self-signed. They are proper, publicly trusted certificates. Also, Let's Encrypt does submit certificates to certificate transparency, so if you really use Let's Encrypt, you should be fine (both now and in the future when you renew).

Re:what does this mean for LetsEncrypt?

[kiviQr]

LetsEncrypt submits all certificates as they issue them: https://letsencrypt.org/certif... More details in cert transparency: https://www.certificate-transp...

Re:what does this mean for LetsEncrypt?

[Nkwe]

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 Encrypt gives low confidence, and you have to spend a decent amount of money to obtain high confidence. What you are paying for when you purchase an expensive EV certificate is the validation process that the CA goes through and the reputation of the CA.

Note that if you control both ends of the network (and the network itself) such as your computer talking to your hardware device across your network, then a self signed or internally issued certificate is fine.

Re: what does this mean for LetsEncrypt?

[Anonymous Coward]

If I have and out of band channel, self-signed certificates are ok, as long as I can obtain the fingerprint through the out-of-band channel.

Re:what does this mean for LetsEncrypt?

[Anonymous Coward]

^^^ "I download and install things I don't understand, but if it appears to work, it's cool."

Wonder no more how so many misconfigured websites, devices, operating systems, etc. exist.

Let's Encrypt supports Certificate Transparency

[tepples]

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:Let's Encrypt supports Certificate Transparency

[Holi]

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?

Re:Let's Encrypt supports Certificate Transparency

[tepples]

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.

Re:Let's Encrypt supports Certificate Transparency

[tepples]

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:Let's Encrypt supports Certificate Transparency

[JesseMcDonald]

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 90 days.

Re:Let's Encrypt supports Certificate Transparency

[AmiMoJo]

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:Let's Encrypt supports Certificate Transparency

[thegarbz]

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 those, and to be frank most of the internet doesn't really need it.

Re:Let's Encrypt supports Certificate Transparency

[sl3xd]

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.

Re:Let's Encrypt supports Certificate Transparency

[Anonymous Coward]

All other cert issuers use the same process (save for EV certs), the only difference being you have to pay for the privilege.

Re:Let's Encrypt supports Certificate Transparency

[Anonymous Coward]

You can use dns verification, where you enter a _TXT record of a specific value that they then verify. I use it to verify internal non-internet routable servers internally here at work.

If you use LE you're fine

[tepples]

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 stating the following: "We submit all certificates to Certificate Transparency logs as we issue them."

Re:Treason Warning

[Anonymous Coward]

If you want to see this new warning, enter "https://www.google.com/?gws_rd=ssl#spf=1"
in the URL section of your chrome browser.

CAP === 'choirs'

Re:Transparency doesn't mean what you think it mea

[Anonymous Coward]

You don't do that yourself, but every single CA either is doing that or will be doing that soon due to the new CA regulations which mandate that every single CA register every single certificate they sign to the public domain. So they do it for you, neat isn't it?

Re:internal apps / ipmi / other things that are no

[Anonymous Coward]

Of course they need real certs IF they are using TLS. What doesn't make sense is those things using https with default certificates just to tick of the "it's secure" checkbox.

CAA records

[tepples]

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 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: CAA records

[Anonymous Coward]

CAA records are useless when I hijack the DNS in the first place. I replace the zone with what I want and surprise, surprise, no CAA record, or a CAA record that specifies LE only.
We are a point where we can no longer afford to separate CA from domain registries, because, you know, the browser does exactly that - makes a certificate and a domain equivalent

Re:CAA records

[WaffleMonster]

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:CAA records

[tepples]

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.

Secure Contexts

[tepples]

Why do home devices need to have trusted SSL certs?

Because Service Workers and several other web platform APIs are restricted to secure contexts per W3C's spec. 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. 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:Secure Contexts

[Actually, I do RTFA]

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:Secure Contexts

[tepples]

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:Secure Contexts

[Actually, I do RTFA]

Ah, it's to verify a whitelist? Cause that's not how JS works (well, it is on my machine, but...)

Re: Secure Contexts

[Monster_user]

Full screen permissions are a whitelist.

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:internal apps / ipmi / other things that are no

[tepples]

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, a W3C spec that reserves certain web APIs for HTTPS sites.

Self-signed certs don't block first-visit MITM

[tepples]

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:Self-signed certs don't block first-visit MITM

[houstonbofh]

A DNS entry like with e-mail would work.

Re:Self-signed certs don't block first-visit MITM

[Anonymous Coward]

Or a wpad type proxy system

Note to management: TIME TO BAN APK

[Anonymous Coward]

Normally I'm not in favor of censorship, but it's time for APK to be banned. His spam posts have again escalated to reporting the same nonsense in article after article. This isn't entirely new, but they also contain violent threats against other users. The law doesn't consider violent threats to be protected speech, and neither should Slashdot. Please get the violent threats off of Slashdot and ban APK.

Multiple routes, expiry, and CT block that

[tepples]

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:

Breadth of hijacking 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? Expiry 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? Certificate Transparency 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.

Re:Multiple routes, expiry, and CT block that

[WaffleMonster]

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:Multiple routes, expiry, and CT block that

[tepples]

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 processing a ton of refunds really cheaper than implementing CT?

What does this mean for me?

[fluffernutter]

I run a small operation and usually try to find the $50 SSL certificate so I can keep going for another year. What does this mean for me?

Re:What does this mean for me?

[Actually, I do RTFA]

I run a small operation and usually try to find the $50 SSL certificate so I can keep going for another year. What does this mean for me?

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 log it, so other cert providers probably do too.

Re:What does this mean for me?

[Anonymous Coward]

It means you're an idiot for paying $50 for a domain validated certificate.

Re: Let's Encrypt supports Certificate Transparenc

[Anonymous Coward]

It also allows the ISP to get intercepting certificates

Passwords and Secure Contexts

[tepples]

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 secure contexts. Without encryption, how should the web developer exhibit this application to the public?

Re:internal apps / ipmi / other things that are no

[dgatwood]

That's partly a reaction to browser implementation of Secure Contexts [pineight.com], a W3C spec that reserves certain web APIs for HTTPS sites.

I think it's more a reaction to browsers popping up security warnings on all non-HTTPS sites.

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 not sure how the industry is going to solve it. The only way I can think of would be to:

• Define a new mDNS device name field in the certificate spec.
• Require that all browsers and devices that implement that field use key pinning in lieu of any guarantee of global uniqueness to the names.
• Require allowing multiple certs with the same name to be pinned with multiple keys (after issuing a stern warning that they are trusting a second device with the same name as an existing device).
• Possibly require browsers to ignore the expiration date for those certificates (because those devices may not be directly connected to the Internet, and thus might not be practical to re-cert).
• Possibly define a standard whereby a browser accessing a device with an old certificate can automatically obtain an updated certificate from the same registrar (or its designated replacement) and upload it to the device without user interaction.

Either way, I'm pretty sure it can't be done practically without making some sort of changes to the standards themselves. That said, I can't be certain of that, because contrary to security best practices, the people who designed the X.509 specification will not make the specification available to security researchers unless they pay $130. So I can only speculate on what the standards say. Aren't standards grand?

DV doesn't protect against typosquatting

[tepples]

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:DV doesn't protect against typosquatting

[thegarbz]

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 like having a door with lock on the front. Probably good enough for your house, but like your example, not good enough to protect the stacks of valuables stored in the Bank of America building.

Re:DV doesn't protect against typosquatting

[tepples]

How is an end user supposed to know where on the sliding scale a particular site is supposed to sit?

Re:DV doesn't protect against typosquatting

[thegarbz]

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 highest risk profile by default is also incredibly draining and wasteful on resources.

The answer is obviously to have a sliding scale of mitigation and educate people how the sliding scale works. DV certificates weren't bad for security, the 90s/00s era end user education where we say if you see a little padlock in the title bar you are 100% safe was bad for security.

Nor do self-signed certs block DNS MITM

[tepples]

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.

How to use the dns-01 challenge

[tepples]

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 client's.
2. Set up zone hosting for that domain on the public Internet.
3. Using your ACME client, begin a dns-01 challenge with the CA.
4. Post the response to this challenge as TXT records in your domain. Your ACME client may be able to perform this step automatically if your zone host's API is supported.
5. Using your ACME client, notify the CA that the response is ready, and retrieve your certificates.

In step 5, Let's Encrypt will contact your zone host through several routes on the open Internet. Nobody will attempt to connect to your internal network.

Re:LMAO @ mental loon Zontar the Mindless

[Anonymous Coward]

country of men w/ NO BALLS & yes, you're from Sweden

What, never heard of Swedish meatballs?

Only new SSL certs need to be in a CT log

[rufey]

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 do for some things), simply turn the clock back prior to May 1, 2018 and issue a new cert that has a long expiration date (say 2+ years). Until they make this retroactive, those certs will not generate an error.

Lets Encrypt and other free services are fairly easy to use, but may not work well with internal-only domains, as they do verification via having you either add a specific DNS entry or a web page on the site's web server, and you have to renew it every 90 days (Lets Encrypt issues SSL certs for a 90-day validity period, others may have a longer validity period).

Re:Only new SSL certs need to be in a CT log

[rufey]

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 or enterprise CAs that are added by users or administrators are not subject to this requirement.

https://groups.google.com/a/ch...

Corporate CAs?

[WaffleMonster]

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/ are flagged as insecure. Again only in chrome.

All resources protected by internal/corporate CA's I assume will now be flagged because none of them participate in log transparency.

I don't have a problem with CT if deployed properly /w user controls and privacy to avoid CT being another excuse for data leakage with widespread coordination and agreement among all stakeholders. But that isn't what happened here. Specifically:

Only Google requiring it with not much in the way of industry buy in.

RFC6962 is an experimental RFC not a standards track document.

Chrome requiring Google CT servers is over the top abuse of power.

Re:Corporate CAs?

[Anonymous Coward]

Well known sites like https://www.kernel.org/ [kernel.org] are flagged as insecure. Again only in chrome.

Just tried it. In Chrome on a Chromebook.

It says 'secure'. No warnings.

Hold on. Patching my MitM

[Anonymous Coward]

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.

Patching my MitM to change issue date of forged certificates.

Re: LMAO @ mental loon Zontar the Mindless

[Anonymous Coward]

Sorry but that's balls.

Swedish meatballs, the national dish of Sweden, have been revealed to have originated from another country - Turkey.

A post on Sweden.Se, the nation's official Twitter account , on Saturday told followers: "Swedish meatballs are actually based on a recipe King Charles XII brought home from Turkey in the early 18th century. Let's stick to the facts!".

http://www.bbc.co.uk/news/blogs-trending-43960739

another change

[jrumney]

Nice to see that you can view the certificate details by clicking on the "Secure" icon in the address-bar again. It was insane when they hid that under Developer Tools so you had to jump through hoops to check why a site was showing up as Insecure.

this is good and bad?

[Anonymous Coward]

I really hope that this is just like a red bar in the URL and not like a page stopping mechanism.

So the PKI isn't that good after all.

[ebvwfbw]

WTH Why is this even needed. SSL Certificates are just that, a certificate. From trusted source. So why do we even need this.

Are you really sure this certificate is ok?

What a long CT list you have Google

[Anonymous Coward]

The better to stalk you with, my dear Chrome users.