Actually true root certs when evaluated by the browsers will have their name constrains within the root certificate themselves ignored.
Modern browsers do respect name constraints of intermediate issuing certificates.
138 karma · joined January 10, 2018
Modern browsers do respect name constraints of intermediate issuing certificates.
The downside of pushing them to that is that that browser will be unlikely to get regular security updates and will likely hide the interception.
In an authoritarian state, you just start blocking and breaking things.
Everything you don't understand, you block. And then you make the user explain it to you and then if it's a use case you care about, you do the work to either decide it doesn't have any danger of carrying traffic you care about or build an intercept scheme for it.
As for whether designating that browser vendors can't distribute software to Kazakhstan, their government would just fork an open-source one, mod it to pre-include their MiTM cert, and force their citizens to use that.
Previously, a government could monitor what site a user is visiting just by looking at the TLS session startup. Even if it is hosted on a cloud provider and 100 different sites are hosted from the same IP, they could look at the TLS-SNI data in the plain text to choose to interrupt and block the connection.
A fallback would be to manipulate DNS queries and force all DNS queries to be directed to official DNS resolvers. But DoH makes that far harder to control.
This is a bluff being called. Tech said "If we make it so that they have to spend all this money and build a massive scale intercept that actively participates in each TLS session, they won't buy into the cost."
Costs keep going down for this sort of thing. Now there are large organizations and governments willing to work on this stuff.
An agency is tasked with doing random sample captures of randomly selected target internet connections.
Inventory all the types of traffic being exchanged.
Flag anything that isn't obvious plaintext or already being MiTM'ed for analysis follow up.
Implement new blocking rules or interception implementation for each flow that isn't already being intercepted.
The way this stuff works is that when GEICO signed the deal to get access to this, they pinky-swore in a contract to only use the data certain ways.
Often, the representatives on both sides of such transactions even have a wink-wink nod-nod deal going which is different from what the contract materially represents.
Importantly, these contracts virtually always avoid talking about mechanisms for tracking such usage, auditing such usage, and even any remedies for violations (beyond discontinuing the service access - and then only if it's egregious).
You'd be amazed how much in the telecom world is handshake and contractual with no technological enforcement and often neither side of these agreements are incentivized to enforce the terms laid out.
The parts of these agreements that are solid is how transactions, events, etc are measured and what these cost and who pays and how. Shocking, that.
There's not a legitimate engineering reason that the network needs to maintain constant fine-grained location data for each registered device at this point. The scope of the registration can be far more widely cast.
This would even have upsides for the devices and users. As check-ins to the network in which the device must transmit to the network would be far reduced, battery life improvements can be had.
Yes, this increases the amount of "broadcast" traffic, but honestly, even for some of the busiest telco switches in New York or LA, those data streams don't even approach the throughput requirements of a single HD Youtube stream...
1. Allow the location data to be utilized by the cellular carrier only for legitimate engineering purposes relevant to the delivery of the cellular services. (The network needs to know your location in real time in order to route calls to you.) Also, allow the use of real time location data for emergency services in response to an emergency call. Potentially also allow the use of emergency services initiated real time locations, with a non-suppressible UI required to be presented to the user if this is performed.
2. Require that the cellular service providers purge / NOT retain this location data for any longer than is literally required to provide proper service.
The data retention policy #2 item here is essential in preventing temptation to come up with end-runs for the first rule. It's important that historic data that has no legitimate use under rule #1 not be preserved so that there isn't a mound of accumulating data of theoretically increasing value if only we could change / get rid of rule #1. That sort of thing will create ever mounting incentive to repeal / replace rule #1.
Because almost all of the CAs utilize a web control mechanism, with many of them probably having processes not as rigorous as HTTP-01, it is likely that there would be significant backlash and a lengthier migration away from the method for that case.
That said, anyone who can would be well advised to figure out how their DNS based mechanism would work if it were ever needed.
As I and others have pointed out, there are clever and fully supported hacks for validating dns-01 without dynamic control of the full domain zone. (CNAME to another zone for the _acme-challenge labels, NS delegation to refer each _acme-challenge label as an independent zone at a different NS, etc.)
You just allow .well-known/* to be passed on to reflect the challenge responses you've generated for the client, while 301 redirecting everything else to their https:// site.
I'm confused how that would be harder for a web host at that scale?
EDIT: I get people trying to run a server off their cable modem / rtr public IP, and 80 might be taken by something other than the target the port forward for 443 is going to -- and that's a problem for those use cases -- but that kind of concern wouldn't exist in a significant hosting infrastructure.
It's naive.
It imagines there was a whole different set of operating circumstances at shared web hosts than the reality exhibits.
I actually had not read the protocol specification for that challenge as I utilize http-01 and dns-01 on all my various systems. Then, when the early report without details was released, I read the protocol and realized almost immediately that there were several circumstances in the field which could yield actual vulnerability.
They also made the mistake of failing to align to a promise which the other mechanisms do make: the other mechanisms tie the validation directly to the target domain label being authorized or a known child thereof. The TLS-SNI-01 and TLS-SNI-02 don't do that. And they knew that, because they wanted to be able to perform a TLS-SNI validation without having to change server software. I believe that was a bad decision.
The proposed TLS-SNI-03 ALPN "acme" extension that Mr. Rudenberg has put forth will not be resilient to these attacks, ultimately. I think they should do a real ALPN protocol and do the validation through that. But let's assume time to market for that would exceed a year. In the mean time, people reliant on TLS-SNI-01 are likely going to need to do something else.
In short, a mechanism which would achieve much the goal of getting validation off of a single TLS port running the right software can happen, but I believe it should borrow pretty much nothing from the current TLS-SNI-0x proposals.
It should be a whole new real ALPN protocol.
I hope that wasn't against protocol.
It will do favor to no-one to rush this. It's broken bad enough that it needs a fresh cycle of iteration and testing.
The Alexa scan idea is weak. Of course no one advertises "acme" as an ALPN name now. There's no incentive to today. If the proposal Mr. Rudenberg made were accepted, there'd be plenty of incentive for these same broken shared hosts to advertise an ALPN identifier of "acme". It just wouldn't be coupled with any incentive to fix the other issues.
On that topic, the proposed edit does not even attempt to define what circumstances/facts/assertions a presenter of the ALPN "acme" is hypothetically promising. No attempt is even made to extract a gentleman's agreement that a shared host vulnerable to the attacks which have been described would not advertise this ALPN. Of course, there's no real point to trying to extract that. The shared host would have no incentive to hold up their end of that promise.
But if this proposal as suggested moved forward without further revision, there would be incentive to make your TLS endpoint with "acme" tomorrow, whether or not your infrastructure is secure against the actual attack vectors that have effectively disqualified TLS-SNI-01 and TLS-SNI-02 at the present.
https://community.letsencrypt.org/t/help-test-certbot-apache...
It seems they are predicting TLS-SNI-0x going away for a lengthy period of time.
That said, the ALPN proposal is a start.
Though rather than just having it as a mere marker, it should incorporate features to securely indicate which domain label it is attempting to validate and achieve consensus on part of validator and the endpoint being validated.
I am hopeful such a scheme may be useful for future deployments down the road. I think it is likely before there is infrastructure in place utilizing a new mechanism of that kind that current needs will need to be met with one of the other mechanisms.
The speed and resource with which Let's Encrypt is working on solutions to migrate users to non-TLS-SNI validations might well be a signal.
You misunderstand how the TLS balancer chooses which certificate to present.
When the TLS connection comes in and presents a SNI name of "a.b.c.acme.invalid", the balancer checks its configuration to see if the host has a "website" called "a.b.c.acme.invalid". It discovers that it does. It looks at what certificate in the database was uploaded for that website configuration.
It doesn't actually check the certificate details at all....
It presents the certificate that was uploaded by the "owner" of the "website" a.b.c.acme.invalid.
And if that name needs to present a certificate that says "d.e.f.acme.invalid" then that is the certificate that the attacker will have uploaded for his "a.b.c.acme.invalid" site.
There are numerous web hosts who would permit this and it would work just like that.
The mechanism you're describing is similar to the changes in TLS-SNI-02. It has already been determined that TLS-SNI-02 is deficient as it is vulnerable to the attack I've parroted here.
The trouble is that the people who wrote both TLS-SNI-01 and TLS-SNI-02 apparently had little knowledge of the vast breadth of behaviors exhibited by a plethora of shared web hosts. The assumptions they made, upon which all the current TLS-SNI-0x protocols rely to provide security, simply are not upheld and honored by the real world marketplace of web hosts.
So attacker requests to validate for a name that you have pointed via DNS to that hosting infrastructure.
The names that you need to respond on and have certs for are then calculated by attacker. Attacker, who is also a customer of same hosting service creates the necessary “sites” and uploads the matching challenge response certs, and successfully receives a cert for your domain.
The ISC BIND DNS server allows cryptographic authentication for updates with ACLs that let you get as granular as only being able to add/delete TXT records within this branch of zone X.
In the alternative, you can place static CNAME records in your real DNS zone that would refer out the _acme_validation queries to another zone entirely. Run that zone with entirely different credentials.
Today's update from Let's Encrypt did allude under "ACME Protocol Updates" that there might be further work done to the protocol to attempt to remediate the risks.
Probably they don't want to get specific because even if a concrete proposal were ready to begin coding today, it would take time to build the reference client, time to build server infrastructure, test, etc.
Then before that work would have any benefit to the various websites needing validation, it would require server software upgrades to facilitate those extensions or ALPN negotiations.
My utter speculation is that they're thinking it would likely take long enough that everyone will have to be off TLS-SNI-01 before its replacement becomes available.
As you point out, domain control validation is best performed by having the application demonstrate control of the domain.
If their plan works out as they've laid out, and as certain recent commits in the boulder source code would suggest...
It would seem they intend to:
1. Allow renewal of already-issued certificates to same account holder to revalidate via TLS-SNI-01 for some limited time period.
2. Whitelist certain shared infrastructure providers who have lots of LE certs in force and who have demonstrated that they are not vulnerable. I'm betting especially for those that manage the whole certificate retrieval and deployment process. It's not clear if this is temporary but longer than #1 or "temporary" but very long term or "temporary" until we come up with another inband process.
3. Otherwise TLS-SNI-01 is gone.
Meanwhile, they'll work with the ACME WG to see if they can't figure out a better TLS-SNI method which would not be vulnerable. That looks less and less workable absent some special TLS extensions or ALPN and server support for those.
For those who have options, it's worth pointing out that the purely DNS based validation methods are literally closest to the facts that the CA's validation process wishes to prove. Domain Control validated means that you're showing effective control of the domain. Nothing says I control the domain like the ability to add and remove data from the authoritative DNS servers for the domain label (and children thereof) in question.
No one ever told the hosted service providers that they should explicitly guard for TLS SNI names unrelated to any name of the customers they host. That certainly doesn't follow from any obvious logic.
I don't believe that a service provider who has this susceptibility is necessarily any more likely to surface other threats.
Having said that, I think what we're all dying to know is what was it, initially, that made Carol so sad?
And, indeed, was it that same sadness which stagnated, fermented, and evolved into the obvious hatred and antisocial behaviors that she exhibits here?
The HTTP-01 and DNS-01 challenges really don't require the web hosts to get their $h1t together to improve security. (Technically, HTTP-01 could for some attack scenarios, but that would still be more difficult than this TLS-SNI-01 attack.) The TLS-SNI-01 mechanism does. Maybe it's the method that's deficient, rather than the web host.
(In truth both are, but one of those can be fixed timely, albeit with a bullet.)
Even if... You would only know for the set of web hosts for the time period you checked each one.
New ones come and old ones die every day.
Even then, you have a CA sticking out its neck on the assurances of a web host that isn't accountable to the root programs and isn't accountable to the CAB Forum.
If that web host swears they don't have the issue, LE tests them, whitelists them, and then subsequently... at a customer request or just to be nasty the web hosts reverts and allows this exploit, the web host won't be held accountable. The CA will.