21–30 of 116 posts
Earlier quoted context omitted.
Will Mitmproxy stop working?
Chrome treats certificates added by user as not requiring CT: https://github.com/mitmproxy/mitmproxy/discussions/5720
> Setting this preference to 2 causes Firefox to enforce CT for certificates issued by roots in Mozilla's Root CA Program.
Would be cool if DANE/TLSA record checks were also implemented. Not sure why browsers are not adopting it.
Would be cool if DANE/TLSA record checks were also implemented. Not sure why browsers are not adopting it.
Impractical in the sense that there are still TLDs ( cc TLDs mind you, ICANN can't force anything for those countries) which do not have any form of DNSSEC, which makes DANE and TLSA useless for those TLDs.
Wonder why they say you should monitor transparency logs instead of setting up CAA records - malicious actors will most likely disregard CAA anyway.
CAA records help prevent unexpected issuance, but what if your DNS server is compromised? DNSSEC might help.
Certificate Transparency provides a detection mechanism.
Also, unlike CAA records which are enforced only by policy that CAs must respect them, CT is technically enforced by browsers.
So they are complimentary. A security-sensitive organization should have both.
Wonder why they say you should monitor transparency logs instead of setting up CAA records - malicious actors will most likely disregard CAA anyway.
Setting CAA records primarily serves to reduce your attack surface against vulnerable domain validation processes. If an attacker wants to specifically attack your domain, and you use CAA, the attacker now needs to find a vulnerability in your CA's domain validation process instead of any CAs validation process. If it works, it prevents an attacker from getting a valid cert.
Monitoring CT logs only detects attacks after the fact, but will catch cases where CAs wrongly issued certificates despite CAA records, and if you monitor against a whitelist of your own known certificates, it will catch cases where someone got your CA to issue them a certificate, either by tricking the CA or compromising your infrastructure (most alerts you will actually see will be someone at your company just trying to get their job done without going through what you consider the proper channels, although I think you can now restrict CAA to a specific account for LetsEncrypt).
Since CT is required now by browsers, an attacker that compromises (or compels!) a CA in any way would still have to log the cert or also compromise or compel at least two logs to issue SCTs (signed promises to include the cert in the log) without actually publishing the cert (this is unlikely to get caught but if it was, there would be signed proof that the log did wrong).
Earlier quoted context omitted.
Will Mitmproxy stop working?
I believe so. You'll need to disable CT enforcement / or add your SPKI hash to the ignore list in the browser settings temporarily to get it working. [0] I guess this is also how corporations get around this issue? Still unsure. [0] https://wiki.mozilla.org/SecurityEngineering/Certificate_Tra...
Can someone explain in a nutshell what CT is, and how does it help security for the average user?
When a CA issues a certificate, it sends a copy to at least two different logs, gets a signed "receipt", and the receipt needs to be included in the certificate or browsers won't accept it.
The log then publishes the certificate. This means that a CA cannot issue a certificate (that browsers would accept) without including it in the log. Even if a government compels a CA, someone compromises it, or even steals the CAs key, they'd have to either also do the same to two CT logs, or publish the misissued certificate.
Operators of large web sites then can and should monitor the CT logs to make sure that nobody issued a certificate for their domains, and they can and will raise hell if they see that happen. If e.g. a government compels a CA to issue a MitM certificate, or a CA screws up and issues a fake cert, and this cert is only used to attack a single user, it would have been unlikely to be detected in the past (unless that user catches it, nobody else would know about the bad certificate). Now, this is no longer possible without letting the world know about the existence of the bad cert.
There are also some interesting properties of the logs that make it harder for a government to compel the log to hide a certificate or to modify the log later. Essentially, you can store a hash representing the content of the log at any time, and then for any future state, the log can prove that the new state contains all the old contents. The "receipts" mentioned above (SCTs) are also a promise to include a certificate by a certain time, so if a log issues an SCT then publishes a new state more than a day later that doesn't include the certificate, that state + the SCT are proof that the log is bad.
Earlier quoted context omitted.
Impractical in the sense that there are still TLDs ( cc TLDs mind you, ICANN can't force anything for those countries) which do not have any form of DNSSEC, which makes DANE and TLSA useless for those TLDs.
Kind of disappointing if that is the actual stated reason by the various browser vendors, all or nothing doesn't sound like a good policy for this. Surely there is a middle ground possible.
This may be controversial, but I believe that with CT logs already in place, DANE could potentially reduce security by leaving you without an audit trail of certificates issued to your hosts. If you actively monitor certificate issuance to your hosts using CT, you are in a much better security posture than what DANE would provide you with.
People praising DANE seem to be doing so as a political statement ("I don't want a 3rd party") rather than making a technical point.
Would be cool if DANE/TLSA record checks were also implemented. Not sure why browsers are not adopting it.
There are basically no rules on how to properly operate it, even if there were, there'd be no way to enforce them. There's also almost zero chance a leaked key would ever be detected.