Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check revocation of DROWN certificates #451

Closed
ivanr opened this issue Jan 18, 2017 · 6 comments

Comments

@ivanr
Copy link
Contributor

commented Jan 18, 2017

When we discover a certificate that makes a server vulnerable to DROWN, we should check that the certificate is publicly trusted, and that includes checking for revocation. See here for the origin of this bug report: https://blog.qualys.com/securitylabs/2016/03/04/ssl-labs-drown-test-implementation-details#comment-108313

@ivanr ivanr added the bug label Jan 18, 2017

@bhushan5640 bhushan5640 self-assigned this May 8, 2017

@bhushan5640

This comment has been minimized.

Copy link
Collaborator

commented May 11, 2017

Fixed, deployed on the dev server.

@fraternl

This comment has been minimized.

Copy link

commented Aug 8, 2017

Hi @ivanr and @bhushan5640

That rogue server on IP 80.101.197.92 is still mentioned.
I don't care that it is mentioned really but by not giving the info that its certificate has been revoked implies that my certificate is somehow less.

I don't know if this is intentional.
https://www.ssllabs.com/ssltest/analyze.html?d=syncthing.mr-wolf.nl

It seems you only changed the scoring behaviour.

I would rather have that SSL2-server mentioned with the extra info that its certificate is revoked or not mentioned at all.
I feel it discredits it now and it shouldn't do that.

If I create a website with a self-signed google.com certificate it does not impact the security of google.com. Nor does that revoked certificate affect my domain. I feel that it therefore should not be mentioned.

@fraternl

This comment has been minimized.

Copy link

commented Aug 8, 2017

https://www.ssllabs.com/ssltest/analyze.html?d=dizzy.mr-wolf.nl&latest

Although your website inform me of the revocation of that certificate, I can still use Chrome to connect to it.
Can you tell me why?
Shouldn't Chrome inform me that this certificate is revoked?
Is it not properly revoked by me (or Comodo) or is Chrome incorrect?
Firefox and IE does detect the revoked certificate
This completely damages my trust in the certificate system if a mainstream browser can't do a core task.

I reported the issue to Google. Hopefully they can give me an explanation.
https://productforums.google.com/forum/#!topic/chrome/RgDg85ujaCU;context-place=forum/chrome

EDIT: googled some more: https://scotthelme.co.uk/certificate-revocation-google-chrome/

So Chrome is fast because it is sloppy???
This means that security is only there for big companies and I can do my best to provide the best security, but it will not be enforced because I'm a silly party not to be taken seriously.....

@anand-bhat

This comment has been minimized.

Copy link

commented Aug 8, 2017

From https://scotthelme.co.uk/certificate-revocation-google-chrome/:

Google Chrome actually utilises its own method of checking for a revoked certificate called CRLSets. In short, Google scoops up all the Certificate Revocation Lists from participating Certificate Authorities, trims the list down to include certificates that they think are important and then sends it out to the browser.
[snip]
The only problem here is that the list is not definitive. If Chrome doesn't have a CRL for a particular CA, it will always trust certificates, even though they may have been revoked.

"Traditional" revocation checks (CRL and OCSP) were removed from Chrome in 2012 (https://arstechnica.com/information-technology/2012/02/google-strips-chrome-of-ssl-revocation-checking/)

@fraternl

This comment has been minimized.

Copy link

commented Aug 8, 2017

Hi @anand-bhat
Just read that article...
And no-one is complaining?

@bhushan5640

This comment has been minimized.

Copy link
Collaborator

commented Aug 9, 2017

@fraternl I think IP should be mentioned in the list, we get the list of such servers from Censys where key or cert hostname matches.

I think status for all such cases (self-signed, revoked etc) should be:
SSL v2 supported (not trusted cert) [in black colour]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.