Aquaboutic | Focus Security Research | Vulnerability Exploit | POC

 Home

two or three things about certificate testing

Posted by melchionda at 2020-03-04
all

Note: This article is the original of Xiaomi safety center. The author: I will sing two sentences casually. Please contact Xiaomi Safety Center for reprint

Last review: automated web security testing

0x00 this is the beginning

At the beginning of the year, there was an article on the Internet titled "accelerating the popularity of HTTPS!"! Google Chrome is going to put a red cross on all HTTP websites. "People who are interested in it can go to Google. History is always strikingly similar. When I didn't answer the questions in school, I had to cross in red. Now, I have to cross in red if I don't deploy HTTPS on the website, as shown in Figure 1. Of course, if you want to turn green, do you see the smiling thumbs of those CA organizations rubbing the middle index finger? Although we need to spend money, and we strongly oppose it on behalf of North Korea, Iran and Syria, this is the general trend.

Figure 1

0x01 certificate introduction

When it comes to HTTPS, we have to mention certificates. For details of TLS protocol and encryption algorithm, we can't press the following table. After all, the article needs to agree on the topic. More importantly, I don't understand these details at present. For some concepts of certificates, there are a lot of materials on the Internet that can help to understand, and can be searched according to the specific details. I won't introduce the terms. At least PKI, X.509 and Ca need to understand. What are the common suffix files such as PEM, CRT, CER, key, der, etc. (see reference 1).

Certificates are generally issued by Ca (root Ca, intermediate Ca, etc.) institutions. Common CA institutions such as Symantec, Comodo, GoDaddy, golbalsign, digicert, etc. can be seen in the general certificate information. However, I feel embarrassed about the sinoretail certification authority that we issue certificates to ourselves. Most enterprise website certificates need to be purchased from these CAS, and the price is not cheap. Of course, there are some free certificates that can be applied for, such as startssl, let's encrypt. It's OK to use these free certificates for personal websites, but I haven't seen any big companies using them yet, of course, I don't exclude that they will be used later, especially let's Encrypt, the trouble is a little trouble, but save money.

Figure 2

For the contents of the certificate, see Figure 2:

The information in the figure has been adjusted to show that it will be more complicated. This information is the premise of the subsequent testing of the certificate.

0x02 certificate detection

Yes, that's the point.

You can also see that it is not difficult to obtain the information of server certificate, is it just a mouse click? However, for a large number of internal domain names of some enterprises, click to check one by one, which is obviously the behavior of IQ not up to standard. I'm a programmer, so I'll say the important things three times: automation, automation and automation.

Speaking of this, some friends may ask, isn't there such a service on the Internet, and some also provide terminal tools. You're talking about sslabs (see reference 2). How can I not know that. It has powerful functions and comprehensive detection, but it is too slow and uncontrollable. The main reasons are as follows:

So what is our goal?

Since the target is so clear, then the next step is to define what will cause the certificate to be untrusted, which is the basis of our detection. There are many reasons. Specifically, I divide them into three categories (welcome to add):

1. The certificate itself has problems

2. There is a problem with the certificate configuration

3. CA organization has problems

With the target, we know the detection item, and then how to detect. We detect one by one the above problems that cause the certificate to be untrusted.

Activate or expire

This is a good test. Most programming languages have certificate related libraries (for Python, I suggest using Python 3 directly. Some useful functions in this regard are Python 2.7.9 later), how to request for certificate information may be different due to different forms of languages, but the general idea is the same. For details, please refer to the manual of the programming language used. Here, I use go to implement. After all, the source code of go standard library is much more beautiful. It should be noted that many libraries themselves have certain certificate validity checks, but they can't be tested according to our needs. What's more, if there is a problem with the certificate, it will directly report an error and can't get the certificate information. Therefore, no matter what language is used and whether the certificate is legal or not, the certificate information must be obtained before subsequent more detailed detection. Therefore, the check on the validity of the certificate should be ignored at the language level to prevent error reporting in advance. Specifically in go, it is (similar to other types):

conn, err := tls.DialWithDialer(dialer, "tcp", domain+":443", &tls.Config{    InsecureSkipVerify: true,  # 设置忽略证书安全性验证 })

It's easy to get the certificate information. There will be two dates in the certificate information, notAfter is the expiration date, and notbefore is the activation date. By comparing whether the current date is between the two, you can judge whether the certificate is activated or expired. It can also calculate the number of days from expiration. When it's about to expire, send an email in advance to remind relevant personnel to apply for a new certificate.

NotAfter NotBefore

Does the domain name match

Whether the domain name matches is also a good test. Because many language standard libraries also provide functions like verifyhostname for detection. But how to detect those cases where the function is not provided? It's easy to say that the specific detection logic is as follows:

verifyHostname

If none of the above three points match, the certificate can be GG. Note: the matching here is absolutely equal for IP, while for domain name, wildcards should be considered. For wildcard matching judgment, please refer to here (see reference 4), * match any field.

*

Is certificate signature secure

As for the signature algorithm, I don't have a complete list. As we know, md2-rsa, md5-rsa, sha1-rsa are all considered to be unsafe signatures. Here we focus on sha1-rsa, because at present, certificates of many websites are still used (as of May 2015, about 45% of digital certificates use this algorithm, and SHA-1 certificates will no longer be considered safe by mainstream browser manufacturers from 2017 All), I'm embarrassed to say that. I won't say the reason. Welcome to MISRC for loopholes.

MD2-RSA MD5-RSA SHA1-RSA SHA1-RSA MD2<MD5<SHA1<SHA2

Knowing these points, it is convenient to detect. The signature algorithm of certificate can be obtained and then compared.

Detection of certificate chain

For certificate chain detection, there are two main aspects, one is the detection of certificate individuals in the certificate chain, the other is the detection of the whole certificate chain. For the former, like the previous server certificate detection, it mainly detects whether the certificate expires, whether the signature is secure, and whether it belongs to a self signed certificate (that is, it is issued by itself, that is, the subjectkeyid is the same as the authoritykeyid). For the detection of certificate chain, it mainly focuses on the following points:

SubjectKeyId AuthorityKeyId AuthorityKeyId SubjectKeyId

The certificate chain length detection is relatively simple, and the certificate information obtained by programming will contain the certificate chain information, which generally exists in the form of a list, as long as the list length is detected.

The detection of certificate order needs to start from the server certificate, and then check whether the authoritykeyid of the certificate is consistent with the subjectkeyid of the next Certificate in the list, so as to ensure that the lower certificate is issued by the higher authority.

AuthorityKeyId SubjectKeyId aKey := certs[0].AuthorityKeyId for _, c := range certs[1:] {    // simply check    if bytes.Compare(aKey, c.SubjectKeyId) != 0 {        paths["chainIssue"] = append(issues, "incorrect order")        break    }    aKey = c.AuthorityKeyId }

The detection of root certificate trust is mainly to detect whether the root certificate in the certificate chain is trusted. Browser and operating system usually bring a large number of trusted CA root certificates, such as:

In addition, there are aosp.pem, apple.pem, microsoft.pem, java.pem, mozilla.pem, etc. as supplements. In a word, you can include all the trusted root certificate collections you know. The more complete, the better. You can even include the root certificates that the browsers do not trust but we think are trusted, such as SRCA. For the detection of trusted CA root certificate, we only need to determine whether the root certificate in the certificate chain belongs to the provided trusted CA root certificate set. The specific implementation is to determine whether the subjectkeyid of the certificate chain root certificate is included in the dictionary (key is subjectkeyid, value can be certificate) composed of the above certificate set, of course, some details are needed. See the code logic here (see reference 5).

aosp.pem apple.pem microsoft.pem java.pem mozilla.pem SubjectKeyId

Other further tests

0x03 who else

The above detection methods are just some methods explored by ourselves. There is no similar solution available for reference on the Internet. Fallacies are inevitable. After all, our party has made a lot of mistakes in crossing the river by feeling the stones. If it helps, I'm glad. If it wastes your time, blame me? Among them, the x509 source code implementation in the go standard library and testssl.sh are of great reference value (see reference 6). If you want to test more accurately, you can consider reading through these source codes and related RFCs, which takes a long time. Friends who have time can study them, and then remember to come back to guide you to correct them.

There are many text descriptions in the article, not too many code pasted, and the specific implementation has been put on GitHub (see reference 7). At present, it is basically available, lacking some document examples. After compiling and running, you will find that the result is very similar to the authentication part in ssltest (see reference 8) detection. I will certainly follow its function to realize it, of course, there will be more or less one Some access, because we are still waiting for our spiritual head Mingo to develop the background interface, so as to further track the test results to repair and adjust.

Well, that's it. Go to picachu, the portal (see resources 9).

Reference material

problem

The following is the ciphertext of a famous website SSL certificate after re encoding (so simple, I can only help you here). Which ca does the root certificate of the certificate come from?

The official account of WeChat:

Xiaomi security center: http://sec.xiaomi.com/

[Note: This is the original of Xiaomi safety center. Author: I'll sing two sentences about safety pulse arrangement and release]

Author: Xiaomi SRC

This article is published by the author of security pulse column. Please note: https://www.secpulse.com/archives/51641.html

© 2023