Certificate trust checking is badly broken. #806
Assignees
Comments
|
Also, the way we check for trust makes no sense as well. DMDirc expects the trust anchor to be present in the given chain, rather than allowing the root of the chain to be trusted by a trust anchor. |
csmith
added a commit
to csmith/DMDirc
that referenced
this issue
Apr 30, 2017
When the user manually trusts a certificate, we should be storing the whole cert instead of just an encoding of its fingerprint. This allows us to display it properly, chain other certs trusted by it, and generally do everything more sanely. Baby step for issue DMDirc#806
csmith
added a commit
to csmith/DMDirc
that referenced
this issue
May 19, 2017
This will replace the two or three kludgy methods in CertificateManager that currently validate hostnames. In the process it fixes some fun problems that could arise if the subject of a certificate contained regex quote sequences (\Q...\E). Issue DMDirc#806
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The way DMDirc checks certificates is completely wrong.
It doesn't verify that the certificates presented actually chain together (the server could give a self-signed cert for itself, then an unrelated certificate for a trusted CA, and DMDirc would be happy).
Obviously we shouldn't be trusting that the certs chain together...
The text was updated successfully, but these errors were encountered: