Tag Info

Hot answers tagged

64

It sounds like your issue is that this vulnerability is bigger than you know what to do with. The rules of responsible disclosure, as decribed here, say that you should contact the vendor and negotiate a period of time - between 1 week and 6 months, depending on the depth of the changes required - in which they can implement a patch, revoke and re-issue ...


33

Such a claim is generally quite serious. While reaching out to the vendor in question is a responsible matter, you should certainly consider notifying the relevant root store security teams, since they are responsible for designing, evaluating, and applying the security controls to prevent this, and will likely need to directly work with the CA to ascertain ...


23

Congratulations! Sounds like a major find. First, generate some proof. The github.com SSL certificate sounds like a great start. Make sure you keep all the network traces you need to show exactly what happened. You need to determine if you broke any laws or T&Cs while doing this. If the CA does not have a bug bounty, you almost certainly did. In that ...


20

There is a standard for that, and, more generally, for all communications with a PKI. It is called CMP. Revocation requests are specified in section 5.3.9. Now, finding a PKI that actually implements CMP... this may be challenging.


18

When unsure, you can also contact CERT: https://forms.cert.org/VulReport/ They have experience in dealing with even very serious security vulnerabilities, and are generally considered a trusted party. At least they can confirm that your assessment of the vulnerability is correct, and document your part in finding it. While CERT generally advises you to ...


7

This is not for "certificates above the end-entity" but for "root certificates" only. In pure X.509, there is no such thing as a "root certificate". There are certificates, and there are trust anchors. A certificate contains a public key, the name of the entity that owns that key, and is signed by another entity (an "upper certification authority"). This ...


6

If the entity is supposed to sign CRL but not certificates, then it is not a CA -- it is a CRL issuer. It is often called an indirect CRL issuer because, by definition, it is distinct from the CA that issued the certificates whose revocation status is specified by the CRL. A certificate may be validated as a CA only if (among other things) it has a Basic ...


4

So I could MITM all https traffic, and spy on my users? No, unless the attacker has the private key for a certificate authority (CA) that is trusted by the user's browser (or intermediate CA that is signed by a trusted CA). A browser does not make requests to a remote certificate authority. Web browsers have a list of trusted certificates of ...


4

As a router, can I send forged certificates, and intercept requests to CA and return responses that they are valid. Yes you could do man-in-the-middle attacks on the router. But you cannot usually do SSL intercepting without the user noticing because the browser warns about invalid certificates. To do interception without these warnings you have to ...


4

In order to perform this task, you typically rely not on a single cert but on an internal certificate authority. You first setup your own , off-line root CA and then immediately setup at least one (usually more) intermediate certificate authority with keys signed by your private root (if you're using a windows AD infrastructure, these ICAs can be setup ...


3

Ryan Sleevi has very good advice regarding this. Before sounding off too many alarms, I would contact the Chromium Security Team as he has advised, just to make sure that you are not misunderstanding anything. Have you checked your vulnerability against the CAB Forum Baseline Requirements to see if the execution of your vulnerability breaks those rules: ...


3

The disadvantage that makes big companies not consider Let's Encrypt is that visitors that connect to the site can't be sure that it is the actual company that hosts the site. This is because Let's Encrypt issues certificates for any webpage freely, without the need for identity validation (personal or corporate) (Let's Encrypt only offers domain ...


3

The reason to use Let's Encrypt can be the price. Those certificates will be for free. But I see one possible disadvantage for nonsmall web sites. Big CA offer wildcard certificates, Extended Validation certificates which have some advantages (from my point of view). Moreover this program is directed to web servers, but what if you have some application ...


3

No, the only way to change the validity date is to re-issue. The reason is that the certificate's hash is calculated after the rest of the certificate is written, editing that field would cause the certificate's hash to change. If the hash is changed anyone else checking the certificate will know it has been altered, but won't be able to tell what changed. ...


3

What does this mean? The certificate changed, as shown by the different SHA1 hashes. The MD5 hash field is no longer relevant as Firefox deprecated them. Can I trust the certificate? No, if it changed without the admin (ie. your) intervention, you should be highly suspicious. How can I check that my certificate is still valid, created by me, ...


1

It depended on the root CA's and it's connection with another CA's. However generally in client authentication, you show your certificate to it, it will check this certificate parent's since it get the root CA. And what happen if the root CA certificate not valid? I think you should report this problem to support team of that CA.


1

Isn't identity proven by the advocate (higher authority) signing a hash of the certificate? Root certificates are built into the system (or shipped with the browser). They are the end of the trust chain and there is no higher authority which signed them. They are self-signed, but only because there has to be some signature. The signature does not need ...


1

I would recommend that you obtain documentation and demonstration of the vulnerability as you are aware of it. Ideally if you can have this verified entirely by a third party, who has been read in to the situation. To avoid issues of integrity or vendor repudiation of the advice on the vulnerability against you, additional proof by demonstration/execution ...


1

As Mike Scott has said, Let's Encrypt describes how they will be authenticating certificates. Remember: SSL issuance practices are entirely standardized by the CAB Forum. Let's Encrypt is following the same rules that all other CAs are required to follow. They are just doing it via the command line. The certificates they will be issuing match the issuing ...



Only top voted, non community-wiki answers of a minimum length are eligible