HTTPS

*복습 자료라서 뻔한 내용은 생략

 

 

Summary.

 

 

1. HTTPS: HTTP over TLS v1.3

     + TLS 1.0, 1.1버전은 이제 브라우저에서 지원 안하는 경우가 많음 (Error)

     + 기본 port는 443 (HTTP는 80)

     + 일종의 HTTP Transaction (query param, message body, 등, encryption 해주지만 ip주소와 port, 전송크기, 전송시간은 숨길 수 없음)

     + public Wi-Fi 패킷 열람이나 private Network 장비의 ads or malware 추가를 위한 packet injection, 등으로부터 안전

 

 

2. Transport Layer Security (a.k.a TLS by IETF)가 보장해주는 것

    + Authentication: lets each party to the communication verify that the other party is who they claim to be

    + Encryption: Data is encrypted while being transmitted between the user agent and the server, in order to prevent it from being read and interpreted by unauthorized parties

    + Integrity: TLS ensures that between encrypting, transmitting, and decrypting the data, no information is lost, damaged, tampered with, or falsified

    + The authentication aspect of HTTPS requires a trusted third party to sign server-side digital certificates (Server Authentication만 되면 충분)

 

 

 

3. Web browsers know how to trust HTTPS websites based on certificate authorities that come pre-installed in their software. Certificate authorities are in this way being trusted by web browser creators to provide valid certificates. Therefore, a user should trust an HTTPS connection to a website if and only if all of the following are true:

• The user trusts that the device hosting the browser and the method to get the browser itself, is not compromised (i.e., a supply chain attack)
• The user trusts that the browser software correctly implements HTTPS with correctly pre-installed certificate authorities.
• The user trusts the certificate authority to vouch only for legitimate websites. (i.e., the certificate authority is not compromised and there is no mis-issuance of certificates.)
• The website provides a valid certificate, which means it was signed by a trusted authority.
• The certificate correctly identifies the website (e.g., when the browser visits "https://example.com", the received certificate is properly for "example.com" and not some other entity).
• The user trusts that the protocol's encryption layer (SSL/TLS) is sufficiently secure against eavesdroppers.

 

 

4. HTTPS 동작과정

1. The client sends a ClientHello which just contains the information of the client’s supported SSL/TLS versions, cryptographic algorithms, etc.
2. The server responds with ServerHello which contains the information about what algorithm it choose from the list of algorithms that it received from ClientHello, the Server’s digital certificate along with the server’s public key, etc.
3. The client verifies if the received digital certificate is valid by contacting the Certificate Authority that issued the digital certificate.
4. Once the authenticity of the webserver is verified from the previous step, ClientKeyExchange takes place. In which a shared secret key for the purposes of Symmetric key encryption is encrypted with the Server’s public key received in Step-2.
5. The client sends a Finished message
6. The server now sends a Finished message encrypted with the key sent by the Client in Step-4, implying that the communication is encrypted.

 

 

5. Digital certificate in simple terms is a certificate issued by some Certificate Authority (CA) which contains 2 things primarily. One thing is the public key of the Server, and the other is Digital Signature that’s been encrypted using private key of the CA who issued that certificate.

 

 

6. Certificate Authority in simple terms, is an entity that does due diligence of the company before issuing them a signed certificate which helps to prove the Authenticity of the company that uses the certificate. The way it works is all major web browsers come with public key’s of major Certificate Authorities throughout the globe. Browser can verify the Authenticity of the certificate by decrypting it using the corresponding public key it has. It’s works as follows, lets say I have my own company ABC with domain abc.com and I want to get a Certificate for encrypting communication between my server and the clients, using https. I go to a popular CA like Google, VeriSign etc and ask them to provide me a Digital Certificate(by creating a Certificate Signing Request(CSR), which we dont need to know about for now). The CA does their own checks and finally issue me a digital certificate which contains ABC’s public key and a digital signature signed using CA’s private key. So anyone who trusts that CA can trust the company ABC

 

 

7. A TLS connection starts with a handshake phase where a client and server agree on a shared secret and important parameters, like cipher suites, are negotiated

    + The primary parameters that the TLS handshake negotiates is a cipher suite 

    + The cipher suite in TLS 1.3 primarily governs the encryption of data

    + Separate negotiation methods are used for key agreement and (server) authentication

    + 같은 cipher suite 여도 이름은 OpenSSL, GnuTLS, 등에서 다르게 사용하기도 함

 

 

8. TLS Server Configure

    +  In general, you should try to limit cipher support to the newest ciphers possible which are compatible with the browsers you want to be able to connect to your site (https://ssl-config.mozilla.org/)

 

 

9. The HTTP Strict-Transport-Security response header (often abbreviated as HSTS) informs browsers that the site should only be accessed using HTTPS, and that any future attempts to access it using HTTP should automatically be converted to HTTPS (intial try susceptible to MITM)

    ex) You log into a free Wi-Fi access point at an airport and start surfing the web, visiting your online banking service to check your balance and pay a couple of bills. Unfortunately, the access point you're using is actually a hacker's laptop, and they're intercepting your original HTTP request and redirecting you to a clone of your bank's site instead of the real thing. Now your private data is exposed to the hacker.

Strict Transport Security resolves this problem; as long as you've accessed your bank's website once using HTTPS, and the bank's web site uses Strict Transport Security, your browser will know to automatically use only HTTPS, which prevents hackers from performing this sort of man-in-the-middle attack

    + The first time your site is accessed using HTTPS and it returns the Strict-Transport-Security header, the browser records this information, so that future attempts to load the site using HTTP will automatically use HTTPS instead

    + Google에서 만든 기능인 Preload HSTS를 사용하면 처음 보는 사이트라고 할지어도 리스트에만 있으면 HSTS 바로 적용해줌

    + HTTPS로 사이트 접속할 때마다 max-age는 갱신되며, max-age는 2년이 권장되는 값임

Strict-Transport-Security: max-age=<expire-time>
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains
Strict-Transport-Security: max-age=<expire-time>; preload

 

 

Additional.

1. TLS 1.3 버전 목표

• Remove unused and unsafe features of TLS 1.2.
• Include strong security analysis in the design.
• Improve privacy by encrypting more of the protocol.
• Reduce the time needed to complete a handshake.

 

2. TLS 1.3 특징

• The TLS 1.3 handshake completes in one round trip in most cases, reducing handshake latency.
• A server can enable a 0-RTT (zero round trip time) handshake. Clients that reconnect to the server can send requests immediately, eliminating the latency of the TLS handshake entirely. Though the performance gains from 0-RTT can be significant, they come with some risk of replay attack, so some care is needed before enabling this feature.
• TLS 1.3 supports (다음에) forward-secure modes only, unless the connection is resumed or it uses a pre-shared key.
• TLS 1.3 defines a new set of cipher suites that are exclusive to TLS 1.3. These cipher suites all use modern Authenticated Encryption with Associated Data (AEAD) algorithms.
• The TLS 1.3 handshake is encrypted, except for the messages that are necessary to establish a shared secret. In particular, this means that server and client certificates are encrypted. Note however that the server identity (the server_name or SNI extension) that a client sends to the server is not encrypted.
• Numerous mechanisms have been disabled: renegotiation, generic data compression, Digital Signature Algorithm (DSA) certificates, static RSA key exchange, and key exchange with custom Diffie-Hellman (DH) groups.

 

3. If the TLS handshake starts to become slow or unresponsive for some reason, the user's experience can be affected significantly. To mitigate this problem, modern browsers have implemented handshake timeouts

 

 

Reference.

• https://medium.com/@mohithmarisetti_58912/https-made-easy-df1b88dc2a0e
• https://en.wikipedia.org/wiki/HTTPS
• https://developer.mozilla.org/en-US/docs/Web/Security/Transport_Layer_Security