The whole PKI concept is dead anyway. Users have been trained to bypass certificate warnings by CA store wars between browsers and OSes, MitM corporate SSL proxies a-la ZScaler / Intune, corporate self signing CAs for intranets and whatnot, blindfolded public CAs giving certs to whatever.
Ssl.com: DCV bypass and issue fake certificates for any MX hostname
51–60 of 66 posts
Re: Ssl.com: DCV bypass and issue fake certificates for any MX hostname
#52The whole PKI concept is dead anyway. Users have been trained to bypass certificate warnings by CA store wars between browsers and OSes, MitM corporate SSL proxies a-la ZScaler / Intune, corporate self signing CAs for intranets and whatnot, blindfolded public CAs giving certs to whatever.
What? When was the last time you had to bypass a cert warning because of "CA store wars" (whatever that means)? What examples can you give for public CAs giving certs to "whatever"?
Re: Ssl.com: DCV bypass and issue fake certificates for any MX hostname
#53And remember kids: there's hundreds of CAs, they all implement validation independently, and you just need one to do one of the three validation methods wrong to make any cert you want. And there's two dozen different attacks that work aside from bugs in validation. Cert validation is swiss cheese. But there's a fix: have the registrars confirm authority to issue certs using a public key uploaded by the domain owner.…
CAA account binding is basically this. Not cryptographically verified but similar idea that the CA confirms you possess a secret (account) before issuing. https://www.rfc-editor.org/rfc/rfc8657
Re: Ssl.com: DCV bypass and issue fake certificates for any MX hostname
#54The whole PKI concept is dead anyway. Users have been trained to bypass certificate warnings by CA store wars between browsers and OSes, MitM corporate SSL proxies a-la ZScaler / Intune, corporate self signing CAs for intranets and whatnot, blindfolded public CAs giving certs to whatever.
What? When was the last time you had to bypass a cert warning because of "CA store wars" (whatever that means)? What examples can you give for public CAs giving certs to "whatever"?
> When was the last time you had to bypass a cert warning because of "CA store wars" (whatever that means)?
Essentially all the time for the last 10 years...
Did you ever try to deploy a website with a certificate from a non public CA? Like, say, your company CA?
If you want it to be valid for Java users, you will have to store your CA cert on the Java trust store.
Want it available for users of Firefox ? Store it in the OS certificate store.
Want it available for Chrome users? Store it in the Chrome certificate store.
Want it available for Python users? Add it to certifi.
And so on.
No single piece of software validating certificates agree on a single CA certificate store.
So, essentially, no company out there supports all these stores, and you just train users to bypass these warnings.
> What examples can you give for public CAs giving certs to "whatever"?
There have been dozens of CAs removed from widespread trust stores for failing to do proper diligence or reporting leaked keys.
Not only that, but essentially I never myself to do any kind of diligence for whatever certificate I requested from public CAs beyond proving I had TXT records update powers at some point in time.
I'm not even mentioning fortune 500 websites running with expired certs.
Re: Ssl.com: DCV bypass and issue fake certificates for any MX hostname
#55Earlier quoted context omitted.
What? When was the last time you had to bypass a cert warning because of "CA store wars" (whatever that means)? What examples can you give for public CAs giving certs to "whatever"?
> When was the last time you had to bypass a cert warning because of "CA store wars" (whatever that means)? Essentially all the time for the last 10 years... Did you ever try to deploy a website with a certificate from a non public CA? Like, say, your company CA? If you want it to be valid for Java users, you will have to store your CA cert on the Java trust store. Want it available for users of Firefox ? Store it in…
> So, essentially, no company out there supports all these stores, and you just train users to bypass these warnings.
This just sounds like a problem with your company. The barrier for getting certs from a public CA is lower than ever now that Let's Encrypt and others exist. If you really must have a non-public CA then your company needs an IT team that can properly manage that.
This isn't an issue for normal users.
Re: Ssl.com: DCV bypass and issue fake certificates for any MX hostname
#56Earlier quoted context omitted.
> When was the last time you had to bypass a cert warning because of "CA store wars" (whatever that means)? Essentially all the time for the last 10 years... Did you ever try to deploy a website with a certificate from a non public CA? Like, say, your company CA? If you want it to be valid for Java users, you will have to store your CA cert on the Java trust store. Want it available for users of Firefox ? Store it in…
> So, essentially, no company out there supports all these stores, and you just train users to bypass these warnings. This just sounds like a problem with your company. The barrier for getting certs from a public CA is lower than ever now that Let's Encrypt and others exist. If you really must have a non-public CA then your company needs an IT team that can properly manage that. This isn't an issue for normal users.
> This just sounds like a problem with your company.
I have seen that pattern in enough companies to be convinced this is widespread.
> The barrier for getting certs from a public CA is lower than ever now that Let's Encrypt and others exist
I don't think you understood what I'm talking about. Public certificates are cute for your public website, but any sizeable company is _also_ hundreds of internal websites and services, especially for the non IT departments. Think legal, compliance, accounting, HR, etc.
Most companies use a private CA for these, and that makes sense:
- You want subsigning CAs for your VPN, contractor services, websites, teams, etc.
- You want private DNS to private IPs (lots of ISPs won't even serve your private IPs through their DNS caches)
- etc
> If you really must have a non-public CA then your company needs an IT team that can properly manage that.
On the contrary, managing private CAs is what most companies do _well_. What they don't (and honestly nobody can) do well is distribute CA certs to user devices. This is often not done right on work devices, but BYOD made it even worst. No company can distribute its CA certs on the hundreds of different stores that one could think of, so after 2 years, some benign change of default corporate browser for users ends up with them learning to auto bypass certificate warnings.
Re: Ssl.com: DCV bypass and issue fake certificates for any MX hostname
#57Earlier quoted context omitted.
> So, essentially, no company out there supports all these stores, and you just train users to bypass these warnings. This just sounds like a problem with your company. The barrier for getting certs from a public CA is lower than ever now that Let's Encrypt and others exist. If you really must have a non-public CA then your company needs an IT team that can properly manage that. This isn't an issue for normal users.
> This just sounds like a problem with your company. I have seen that pattern in enough companies to be convinced this is widespread. > The barrier for getting certs from a public CA is lower than ever now that Let's Encrypt and others exist I don't think you understood what I'm talking about. Public certificates are cute for your public website, but any sizeable company is _also_ hundreds of internal websites and se…
> You want private DNS to private IPs
Nothing stops you getting a cert while pointing your DNS records to internal addresses. The DNS-01 challenge exists to serve exactly that kind of configuration.
> lots of ISPs won't even serve your private IPs through their DNS caches
I have never seen this, could you give an example? However, if this is an issue then there's nothing stopping you from just using your public DNS for DNS-01 challenges and using your internal DNS for everything else.
It is also impossible for your ISP to do this if you're using DoH or DoT, which you really should be, especially if you already know that your ISP is messing with DNS traffic.
> You want subsigning CAs for your VPN, contractor services, websites, teams, etc.
You can't do this, but you can have your own ACME server that forwards requests to a public CA if you really need to let different teams manage their own certs. A better option is probably to use one of the paid CloudFlare tiers where you can create scoped API keys that provide DNS editing access scoped to a subdomain, or you could of course host your own DNS server or find a different DNS provider that offers this service.
Re: Ssl.com: DCV bypass and issue fake certificates for any MX hostname
#58Earlier quoted context omitted.
> This just sounds like a problem with your company. I have seen that pattern in enough companies to be convinced this is widespread. > The barrier for getting certs from a public CA is lower than ever now that Let's Encrypt and others exist I don't think you understood what I'm talking about. Public certificates are cute for your public website, but any sizeable company is _also_ hundreds of internal websites and se…
> You want private DNS to private IPs Nothing stops you getting a cert while pointing your DNS records to internal addresses. The DNS-01 challenge exists to serve exactly that kind of configuration. > lots of ISPs won't even serve your private IPs through their DNS caches I have never seen this, could you give an example? However, if this is an issue then there's nothing stopping you from just using your public DNS f…
We have a team who uses a ".dev" domain for local development (with a publicly issued SSL cert), with an A record of 127.0.0.1.
We had someone new join the team and couldn't get the dev environment working. Turns out his ISP's DNS wouldn't resolve to an internal IP. Simple fix was updating his system DNS away from his ISP. We only saw this happen to one person, so wouldn't say it's common but it happens.
Re: Ssl.com: DCV bypass and issue fake certificates for any MX hostname
#59Earlier quoted context omitted.
> You want private DNS to private IPs Nothing stops you getting a cert while pointing your DNS records to internal addresses. The DNS-01 challenge exists to serve exactly that kind of configuration. > lots of ISPs won't even serve your private IPs through their DNS caches I have never seen this, could you give an example? However, if this is an issue then there's nothing stopping you from just using your public DNS f…
We have a team who uses a ".dev" domain for local development (with a publicly issued SSL cert), with an A record of 127.0.0.1. We had someone new join the team and couldn't get the dev environment working. Turns out his ISP's DNS wouldn't resolve to an internal IP. Simple fix was updating his system DNS away from his ISP. We only saw this happen to one person, so wouldn't say it's common but it happens.
That's protection against DNS Rebinding attacks -- you don't want external domains to be able to make same origin requests to internal domains, and while it suffices to only block changing resolution, that's harder than blocking internal IPs altogether.
Re: Ssl.com: DCV bypass and issue fake certificates for any MX hostname
#60Public service announcement: CAA records exist and allow you to whitelist the CAs you trust to issue certificates for your domain. https://letsencrypt.org/docs/caa/ You can use https://www.entrust.com/resources/tools/caa-lookup (or e.g. `dig caa paypal.com`) to see if any domain is protected. https://isc.sans.edu/diary/26738 is a cautionary study from 2020 indicating only 3% of the Alexa top 1M had CAA records. And j…
It may also be worth mentioning that when using CAA and also using something like LetsEncrypt one can specify which account is permitted to create and update certs and which method is approved DNS in this case. [1]
Example using DNS validation:
0 iodef "mailto:domainowner@example.net"
0 issue "letsencrypt.org; validationmethods=dns-01; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/xxxxxxxxxx"
0 issuewild "letsencrypt.org; validationmethods=dns-01; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/xxxxxxxxxx"