#HTTPS #SSL #PKI
One of the things I learned from the Chromium analysis is that more JavaScript methods can be used in web pages accessed via https than http. That is, Chrome grants differentiated rights to web pages according to the scheme. ”http://“, ”https://“, “chrome://“ more powerful? method can be called. The chrome scheme is, of course, different from other schemes in terms of functionality and security because it deals with parts related to the operation of Chrome like the settings page of Chrome (chrome://settings)… Others were quite surprised.
It’s hard to find non-http websites since Chrome started warning that web pages with the http scheme were not secure. However, for web developers, it is cumbersome to test a website being developed with https. This is because you need to purchase a certificate that proves that the website is a secure site. Looking at the sites referenced in writing this post, I could see that there were already many developers who wanted to test more easily.
I thought about how great it would be if I could connect to the localhost with https. I’m also interested in web development, but I’m more interested in the JavaScript engine than that, so I started looking for it, and there were already great trials and errors. These are the parts you just have to follow. However, I was curious about the general principle of https including certificates, so I put them together separately. For reference, the JavaScript engine runs in a ‘secure context’ for https, allowing method calls with more privileges. See web page below.
https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts
HTTPS(HTTP over SSL) ¶
One question. Chrome warns you that it is an unsafe site when you access a web page with the http scheme. In other words, a web page with an https scheme is secure, but how does Chrome know that it is secure? It is only possible to know through an absolutely trusted third party. In this case, the certificate is used. In order to understand the overall mechanism, we first had to know about ‘Asymmetric Cryptography’ and ‘Digital Signature’.
Asymmetric encryption (= public key encryption) ¶
In symmetric key encryption, the key used to encrypt or decrypt data is the same. The disadvantage of symmetric key encryption is that if the key is leaked, the data is also leaked. For this reason, it is used in file compression that keeps the key alone, and BitLocker, a Windows volume encryption function. What if two people want to have “secure” cryptographic communication? In this case, asymmetric encryption is utilized. In asymmetric encryption, the key used for encryption and the key used for decryption are different. When there are two pairs of keys, A and B, encryption with key A is decrypted with key B, and encryption with key B is decrypted with key A. This post does not contain mathematical contents about asymmetric encryption.
Public key signature verification, public key encryption/decryption ¶
What is asymmetric encryption really useful for? As mentioned earlier, it can be used for cryptographic communication between two people. To this end, one of the key pairs is designated as a private key and the other as a public key. The private key should never be made public, and the public key may be made public. No, it is meaningful that it should be disclosed. Are you going to reveal the key? Because of this peculiar characteristic, asymmetric encryption is also called “public key encryption”. You can do two things with public key cryptography. Those are ‘public key signature verification’ and ‘public key encryption/decryption’. First, the public key signature consists of the following procedure.
Public key signature verification ¶
- Withdrawal: Send the original data text and the cipher text encrypted with the secret key together. 2. Younghee: Receives the original text and the cipher text and compares the original text and the decrypted text decrypted with the public key.
When the decrypted text and the original text match, Young-hee can be sure that the sender of the data is the withdrawal. At this time, the cipher text sent by Cheol-su can be decrypted by anyone with the public key. This process is called “signature” because it is the same as authenticity verification and identity verification using a seal.
And public key encryption/decryption is performed in the following procedure.
Public key encryption and decryption ¶
- Younghee: Sends the ciphertext by encrypting the original data with the public key. 2. Withdrawal: Receive the cipher text and decrypt it with the secret key.
Compared with the previous public key signing process, Cheolsu can use the private key to decrypt the ciphertext encrypted by Younghee with the public key. However, since the secret key literally only has the cipher, no one other than the cipher can decrypt the cipher text. That is, by exchanging each other's public key, two people can confirm each other's identity and send and receive data safely by encrypting data with each other's public key.
Electronic communication using only public key cryptography is known to have poor performance. In my personal opinion, it would be very inconvenient since the data to be transmitted must be encrypted with the public key of all recipients and transmitted individually to each recipient in the case of multi-party encrypted communication. In fact, public key encryption is used only for sharing a symmetric key, and actual communication is performed using the symmetric key.
Public Key Infrastructure (PKI) ¶
Encryption communication is impossible by simply knowing public key encryption. ‘Public key infrastructure’ is a term that includes all elements necessary for cryptographic communication based on public key encryption. This includes the contents of a certificate and a certificate authority (CA), which will be described later.
SSL(Secure Sockets Layer) ¶
With the development of the web, secure communication through the web has been required. Because we had to determine whether the web page the user was viewing had been tampered with. For this purpose, Netscape early developed ‘SSL’ according to the PKI structure. Later, as it was established as a standard, it was renamed TLS (Transport Layer Security). https is a web protocol that runs on top of this SSL.
The overall operation of HTTPS ¶
The operation of the https protocol is as follows. Previously, in public key signatures, when the sender sends the original data and the encrypted text with the private key, the receiver can verify the identity of the sender by whether the decrypted text obtained by decrypting the encrypted text with the public key matches the original text. At this time, the cipher text is called “sender’s signature”. Similarly, in the https protocol, the source of data contains the ‘server domain’ and ‘server public key’ that the user wants to access. Source of data and ‘server signature’ is called a ‘certificate’. The part that assumes that you already know the public key of ’ is broken, which leads to serious security flaws. For example, a user who accesses “https://www.google.com” contains the public key of the Google server from the Google server. I received the certificate. Of course, the certificate will be verified with the public key included in the certificate. The question is whether the Google server is a real Google server. If the user entered the wrong address and accessed “googlee.com”, then “googlee.com” is malicious. What if you are impersonating “google.com” with the intention of being
CA (Certificate Authority) ¶
In the end, you have to verify that the certificate you presumed to have received from the Google server is trustworthy. Otherwise, we have to go directly to Google’s headquarters in San Jose, USA to get the public key of Google’s servers. Similarly, to use Naver, you must go to Naver’s headquarters in Bundang and obtain a public key. However, since this is not possible, the part that verifies the certificate through a third party is included in the PKI. This third party is called a ‘Certificate Authority’ (CA). The role of the CA is to verify that the certificate of the server to which the user is connected can be trusted.
Certificate Chain ¶
Again, in the scenario where the user accesses “https://www.google.com”, the user will receive a certificate from the Google server. This certificate contains ‘server domain’, ‘server public key’, as well as ‘CA domain’ and ‘CA signature’, not the server. To verify this certificate, you need the CA’s public key because the signature is that of the CA. At this time, the meaning that the signature of the certificate is verified can be interpreted as follows.
- The signature of the certificate has been verified - == The certificate is authentic signed by the CA - == The server that sent the certificate is trusted - == The public key included in the certificate is the server's. Where the hell are you? It is in the 'CA certificate' that is included in the operating system and Chrome browser in advance. In the end, it looks like the server certificate is verified with the CA certificate. This is called a 'certificate chain'. CA itself is inevitably trusted. For this reason, it is not good for security to use software from unreliable sources, such as using a cracked operating system or web browser.
Self-signed SSL ¶
Because of the above complex PKI structure, it is not easy to test a website that is served as https in advance. This is because the domain and server public key of the website to be tested must be sent to the CA to obtain a server certificate. To recap, this certificate contains the following:
- Server Domain - Server Public Key - CA Domain - CA Signing
In the end, the website developer is in a situation where he has to obtain a certificate from a CA for the test website. (It is unlikely that a strict CA will issue a certificate for the test website anyway).
If so, how great would it be if I could act as a CA myself? If you search with the keyword Self Signed SSL, many articles are already pouring out. Among them, I would like to introduce the process of self-signing the certificate for localhost.
1. (CA side) Generate CA secret key ¶
In order to act as a CA (root CA), a private key and a public key must be generated as a CA. The following command uses a program called OpenSSL to generate a 2048-bit secret key with RSA (Rivest-Shamir-Adleman), a representative public key encryption algorithm, and store it in rootCA.key. The des3 option means to encrypt the secret key once more with 3DES (Triple Data Encryption Standard), a symmetric key algorithm. Because the secret key must never be leaked, it is for protection once again, and the encryption key will be requested immediately after entering the command below.
$ openssl genrsa -des3 -out rootCA.key 2048
// rootCA.key 생성됨
2. (CA side) Generate CA certificate ¶
Through the command below, a public key for CA that is paired with a private key for CA is generated, and a CA certificate signed with the CA private key is generated for the public key and basic information of the CA. The CA certificate generated in this way will be registered as a trusted certificate in the web browser or operating system. Subsequently, whether the server certificate received from the local web server is trusted is determined using this CA certificate. The x509 option means to generate a certificate in X.509 format, and the nodes (not the plural form of node…) option means not to encrypt the public key for CA. The sha256 option means to use the SHA256 hash algorithm for signature generation. In fact, when generating a signature, data is not encrypted with the private key as it is, but data processed with a hash value is encrypted with the private key. The days option sets the validity period of the certificate. This command creates a certificate that is valid for 1,024 days. Eventually, a CA certificate called rootCA.crt is created.
$ openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.crt
// rootCA.crt 생성됨
If you run the above command, you will be asked for a password to use the CA private key to generate the CA public key and to generate the CA signature. For this password, input the symmetric key used when encrypting the CA private key with DES3. Next, we will ask you some basic information as a CA. For example, information such as the CA’s nationality, name, and domain.
3. (Server side) Generate server secret key (can be omitted) ¶
Now it’s time to generate the server secret key. Enter the following in the same way as the CA secret key was generated. There is no des3 option, but the des3 option is the default option. First, the server secret key will not be generated now, but will be generated in the next process.
$ openssl genrsa -out server.key 2048
// server.key 생성됨
4. (Server side) Generate server private/public key and CSR ¶
Typically, a web developer must send a server domain and server public key to a CA and request to issue a server certificate signed with the CA private key. This request is called a CSR (Certificate Signing Request). Information necessary to generate CSR can be written in a separate file and provided to OpenSSL. If you look at server.csr.cnf below, server information is written in “[dn]”. At this time, the CN field must be entered correctly. Even if the server certificate is signed by the CA, if the domain of the site the user wants to access is not included in the domain listed in the CN field, the browser blocks the access. The reason for the blocking is that a typo occurred when writing the CSR, or the certificate was issued incorrectly to the wrong site because the CA’s private key was leaked. Both cases lead to serious security incidents. It is said that a CA called Diginota went bankrupt due to the leak of the secret key.
# server.csr.cnf (for creating csr)
[req]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn
[dn]
C=US
ST=RandomState
L=RandomCity
O=RandomOrganization
OU=RandomOrganizationUnit
emailAddress=hello@example.com
CN = localhost
The command below creates a CSR called server.csr based on the server information in server.csr.cnf created above. At this time, the server private key created with the newkey option is also used. It was explained that the server public key is included when generating the CSR. In fact, when OpenSSL generates the private key, it already includes the public key as well as the private key. This will be further described below. Anyway, the generated CSR is signed with the server secret key. In the end, server.key, which is a server secret key, and server.csr, which is a CSR, are generated.
$ openssl req -new -sha256 -nodes -out server.csr \
-newkey rsa:2048 -keyout server.key \
-config <( cat server.csr.cnf )
// server.key, server.csr 생성됨
5. (CA side) Generate server certificate ¶
The CA needs to send the server certificate signed by the CA private key with the CSR received from the server. Extension fields can be added to certificate generation. If you look at the v3.ext file below, the third extension of the X.509 standard, which is the format of the certificate, is contained. These extensions include a Subject Alternative Name (SAN) field that allows you to trust multiple domains with a single certificate.
# v3.ext(for creating X509 v3 certificate)
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = localhost
The command below creates a server certificate by attaching the X.509 extension field contained in v3.ext created earlier to the previously created CSR server.csr. This certificate is signed with the CA private key, rootCA.key. Eventually, a server certificate called server.crt is created.
$ openssl x509 -req -in server.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial \
-out server.crt -days 500 -sha256 -extfile v3.ext
// server.crt 생성됨
+. Generation of private/public key ¶
What I was curious about while following the above process was that there was no process of explicitly generating the public key even though the private key and public key were a pair. It was suspected that the public key was included in the private key, but the genrsa command of OpenSSL only said to generate the private key. In fact, what is generated by genrsa is various factors necessary for generating private and public keys, and they are said to be used to quickly generate private and public keys whenever necessary.