SSL/TLS, HTTPS 기초 개념

대표적인 암호화 방식

1. 공유키 암호화(대칭키 암호화), Symmetric cryptography

- '하나의 키'로 암호화와 복호화를 하는 방식
- 암호화, 복호화 속도가 빠르다는 장점이 있지만 키를 안전하게 공유하는 방법이 어려움
- 키를 공유하는 과정에서 탈취가 발생하면 문제가 될 수 있음
- 암호화된 데이터를 공유할 모든 사람에게 같은 키를 나눠줘야 하는 과정이 쉽지 않음
 

2. 공개키 암호화(비대칭키 암호화), Asymmetric cryptography

- 암호화와 복호화에 쓰이는 키가 서로 다른 방식
- 이때 암호화에 쓰인 키와 복호화에 쓰인 키가 하나의 'pair'를 이룸
- 한쪽 키로 암호화한 것은 다른 한 키로만 복호화할 수 있음
- 두 키를 개인키(비밀키), 공개키라고 부르며 공개키는 암호화된 데이터를 읽을 사람에게 공개함. 공개키를 가진 자는 암호화된 데이터를 복호화할 수 있지만, 개인키가 없기 때문에 암호화는 할 수 없음.

 

 

---

 

전자 인증서(Certificate)와 전자 서명(Signing)

공개키(비대칭키) 암호화 방식을 사용하여 데이터 유출을 막을 수는 있지만 공개키를 보낸 서버가 실제 서버를 가장한 사칭 서버일 가능성도 있다. 만약 그렇다면 누구인지도 모르는(인증되지 않은) 사람에게 데이터를 넘겨주는 것과 같은 위험이다. 따라서 데이터를 암호화했더라도 실제 인증된 서버와만 통신해야 하며, 이때 서버는 본인이 자기 자신임을 증명할 수 있는 수단이 필요하다. 또한 원본 데이터의 위변조를 막기 위한 방법으로 전자 서명(Signing)이 활용된다. 즉, 특정 데이터가 위변조되어 있지 않고 원본이라는 것을 증명하는 것이 전자 서명이며 증명서와 서명은 비슷해 보이지만 사용용도가 다르다.

 

정리하자면, 전자 인증서는 서버가 본인이 자기 자신임을 증명하기 위한 것이며 전자 서명은 데이터의 원본임을 증명하기 위한 것이다. 

 

 

인증 기관(CA, Certificate Authority)의 보증

서버가 본인이 자기 자신임을 증명하기 위해 인증서가 필요하지만 해당 인증을 해줄 주체가 필요하다. 이를 위해 공개적으로 인증된 별도 '인증 기관'이 발행한 전자 인증서를 사용한다.

 

[서버의 인증서 발급 절차: Certificate signing request(CSR, 인증서 서명 요청)]

1) 서버는 인증 기관에게 자신이 사칭한 서버가 아님을 증명하고 본인의 공개키를 인증기관에게 보낸다.

- csr 파일을 기반으로 CA에 인증 서명 요청을 보낸다.

 

2) 인증 기관은 서버의 공개키가 서버 본인의 것이라는 것을 증명하는 전자 인증서를 서버에게 발행한다.

- CA는 자신의 private key로 csr에 서명한다.

3) 서버는 클라이언트와 커넥션이 맺어질 때 전자 인증서를 보내서 사칭된 서버가 아님을 확인시킨다.

- 서명된 인증서(cert file)는 다시 서버로 보내진다.

- 모든 브라우저는 CA의 public key를 가지고 있기 때문에 서버의 인증서 파일을 CA의 public key를 기반으로 인증 과정을 진행한다.

 
전자 인증서는 인증 기관에 요청하여 받을 수 있는데, 발급받은 전자 인증서 안에는 보통 '서버의 공개키'와 '인증 기관의 전자 서명'이 포함되어 있다. 여기서 인증 기관의 전자 서명은 "이 공개키는 이 소유자의 것이다"라는 것을 보증(원본 보증)하는 역할을 한다.

 

 

cf. CA 인증서 파일 확장자

CA 인증서 파일의 확장자는 일반적으로 .pem, .cer, .crt 등이 사용된다.

 

cf. 국내, 글로벌 CA

- 국내: 한국정보인증, 코스콤, 한국전자인증, 한국무역정보통신, 금융결제원 등
- 글로벌: DigiCert, 버라이즌, GlobalSign 등
* DigiCert Global CA G2 가격을 보면 1년에 400달러 정도 한다. 더 안전한 사이트를 만들기 위해 let's encrypt(https://letsencrypt.org/) 라는 기관에 여러 회사들이 투자하여 이 단체가 운영되고 있다. 이 기관에서는 인증서를 무료로 발급받을 수 있다.

 

cf. 전자 서명 원리

- 전자 서명을 만들기 위해선 원본 데이터의 해시값(메시지 다이제스트)을 구하고 이것을 공개키가 아닌 (인증 기관의) 개인키로 암호화한다. 개인키로 암호화된 데이터는 (전자 인증서에 포함된) 공개키로 복호화할 수 있다. 복호화하면 메시지 다이제스트가 나오는데 해당 값이 일치하는지 비교하여 위변조된 데이터인지를 확인한다.
- 메시지 다이제스트는 일종의 데이터에 대한 요약 정보로 해시 함수 또는 데이제스트 함수를 통해 생성된다.
 
 

cf. PKI(Public Key Infrastructure)

공개키 암호를 사용한 기술과 인증 기관에 의한 인증 시스템 전체(공개키, 개인키, 전자 서명, 전자 인증서, 인증 기관, 수칙 및 절차, 기법 등)를 통틀어 PKI라고 부른다.
 
 

cf. OS 별 전자 인증서를 보관하는 위치

[Windows]
- 로컬 컴퓨터 저장소: certmgr.msc -> 인증서 - 로컬 컴퓨터
- 사용자 저장소: certmgr.msc -> 인증서 - 사용자 계정
 
[MacOS]
- 시스템 저장소: /Library/Keychains/System.keychain
- 로그인 키체인: ~/Library/Keychains/login.keychain-db
 
[Linux]
- CentOS, RHEL: /etc/pki/tls/certs/
- Debian, Ubuntu: /etc/ssl/certs/

cf. 쿠버네티스 클러스터: /etc/kubernetes/pki/

 

[Java 애플리케이션]

- Java는 VM에서 구동되는 애플리케이션이기 때문에 OS와 상관없이 SSL 인증서를 따로 관리한다.

- 이와 같이 JVM에서는 OS와의 종속성을 제거하기 위해 KeyStore 라는 개념을 도입한다. 이 KeyStore에는 인증서의 정보뿐만 아니라 클라이언트(Java app)의 개인키와 인증서 체인 정보도 함께 저장된다. 

- SSL 인증서의 관리 및 갱신을 자바 애플리케이션에서 직접 관리할 수 있다.

- cacerts 파일 인코딩 형식: Java KeyStore(JKS) 

- truststore: Java 클라이언트가 신뢰된 서버의 CA 인증서를 보관하는 위치

- truststore 위치: $JAVA_HOME/lib/security/cacerts

- Java는 KeyStore를 관리하기 위한 커맨드로 'keytool'를 제공한다.

 

keytool로 인코딩된 인증서 확인

 

 

cf. JVM default TrustManager

- TrustManager는 서버의 CA 인증서를 받은 클라이언트가 해당 인증서에 대한 검증을 하기 위한 주체이다.
- JVM에서 제공되는 default TrustManager는 ‘X.509 형식의 인증서’를 검증한다. (X.509 형식의 인증서에는 CA 서명(Signing), 서버 공개키 등이 포함됨).

- X.509 형식의 인증서만 검증할 거면 JVM default TrustManager를 사용해도 되지만 그 외 다른 인증서 형식도 지원하려면 추가 TrustManager가 필요하다.

---

 

SSL(Secure Sockets Layer) / TLS(Transport Layer Security)

- 암호화 및 복호화를 할 때 공개키(비대칭키) 방식과 공유키(대칭키) 방식을 모두 사용한다.
- SSL과 TLS: SSL은 넷스케이프 커뮤니케이션즈가 개발했고 IETF에서 1999년에 SSL 3.0을 TLS라는 이름으로 표준화했다. 현재 SSL이라는 말이 사용되고 있긴 하나 TLS라고 말하는 것이 더 정확하다.
- TLS는 L5(Session Layer)에 속하는 프로토콜로 TCP(L4) 기반이다. (참고로 UDP 기반의 보안 프로토콜인 DTLS는 TLS의 대부분을 차용한 프로토콜이다)
 

TLS Handshake 절차

https://www.imperva.com/learn/performance/cdn-and-ssl-tls/

 
0) L4 레벨 통신 진행: TCP handshake

 

1) Client Hello

- 클라이언트가 서버로 접속 요청을 하는 과정이다.

- 클라이언트는 자신이 해독할 수 있는 암호화 알고리즘 리스트도 보낸다(cypher suites)

 

2) Server Hello

- 서버는 클라이언트의 cypher suites를 제공할 수 있는지 확인한다. 제공할 수 있다면 인증과정이 시작된다.

- 인증과정: 서버는 인증 기관으로부터 발급받은 자신의 전자 인증서를 보낸다.

- CA 인증서에는 서비스(서버) 정보, 서버 공개키 등이 포함되며 CA의 디지털 서명으로 원본이 보장되어 있다.

 

3) 클라이언트 서버 인증과정

- 클라이언트는 서버로부터 받은 인증서를 통해 서버의 신원을 확인한다. (Trust manager)

- 난수를 통해 공유키(대칭키)를 생성한다.

- 생성한 공유키(대칭키)를 '서버의 공개키로 암호화'하고 서버로 전송한다. 공개키는 노출되어도 되지만 다행히 암호화밖에 하지 못한다.

 

4) 통신을 위한 대칭키 추출

- 서버는 '암호화된 클라이언트의 대칭키를 자신의 개인키로 복호화'한다. 여기서 복호화는 개인키를 가지고 있어야지만 가능하기 때문에 서버만 할 수 있다.

 

5) L7 통신 진행 (HTTPS, FTPS 등)

- 이후 서버는 데이터를 보낼 때 클라이언트로부터 받은 대칭키(symmetric-key)로 암호화하고 데이터를 보낸다. 어짜피 대칭키 값 자체는 암호화된 형태로 단 1번만 네트워크 상에 보내졌으므로 대칭키가 노출되었다 하더라도 암호화된 대칭키일 뿐이다.

- 클라이언트는 암호화된 데이터를 받으면 '같은' 대칭키로 이를 복호화한다.

- 이러한 과정을 통해 계속해서 공유키를 기반으로 암호화된 데이터를 통신한다. 여기서 공유키로 통신한다는 것은 공유키로 보낼 데이터를 암호화하고 복호화하는 데 사용한다는 것이다. (키를 매번 보내는게 아님)

 

 

- 패킷 캡쳐 결과, TCP 커넥션 후 바로 Client hello, Server Hello, Application data 전송이 이루어졌음을 확인할 수 있다.

 

 

[Flow 정리]

1) 서버가 비대칭키를 만들고 그중에서 자신의 public key를 클라이언트로 보냄.

2) 클라이언트는 대칭키를 하나 만들고 이 키를 서버로부터 받은 public key로 암호화함.

3) 암호화된 대칭키를 서버로 보냄.

4) 서버는 이 대칭키를 자신의 private key로 복호화함

5) 클라이언트가 HTTP 요청을 보낼 때 메시지를 대칭키로 암호화하고 보냄.

6) 서버는 HTTP 응답을 보낼 때 똑같은 대칭키로 암호화하고 보냄.

 

 

cf. 추가 개념

* 사실 클라이언트가 서버의 public key를 받을 때에는 CA인증서 파일과 함께 받고 서버의 인증과정이 동반된다. 인증서 또한 가장된 서버도 만들 수 있다. 그래서 인증서에서 가장 중요한 것은 CA의 전자 서명이다. 즉, 누가 이 인증서에 서명을 했는지가 중요하다는 것이다. 여기서 서버가 직접 '서명'을 한 인증서를 Slef-Signed Certificate라고 한다.

- 결국 HTTP 메시지를 암호화, 복호화하는데 사용되는 대칭키는 서버의 public key로 암호화된 상태로 네트워크에 흘려졌기 때문에 해당 대칭키가 해커에 의해 유출되었더라도 이를 복호화할 수 없다.

- 암호화된 대칭키가 네트워크 상에서 보내지는 것은 단 1번뿐이다. 계속해서 키를 암호화하여 보내지 않는다. 즉, client hello, server hello는 거의 한 번의 RTT만에 이루어지는 것이다 이를 1-RTT라고 한다. 또한 클라이언트는 이전에 방문한 서버 기록이 있다면 TLS 세션을 만들 때 걸리는 통신을 하지 않는다. 이를 0-RTT라고 한다. 따라서 거의 0~1-RTT 만큼 소요되기 때문에 성능상 단점도 거의 없다.

 

 

---

 

 

키, 인증서 생성 및 서명 과정

1) 서버 측

1. private key 생성

openssl genrsa -out server.key 2048

2048비트 RSA 알고리즘을 사용하여 새로운 키를 생성하고, 해당 키를 server.key 파일에 개인키로 저장

 

* cf. openssl은 TLS 구현체 오픈소스 중 하나이다. 참고로 L5에 속하는 TLS는 TCP/UDP와 다르게 OS 레벨의 기능이 아니며 애플리케이션 단 기능으로 보는게 맞다. 따라서 openssl은 대략 보안 관련 미들웨어로 취급된다.

 

 

2. 인증서 서명 요청 생성

openssl req -new  -key server.key -subj "/CN={Common Name}" -out server.csr

 

- Common Name (CN)은 생성되는 CSR에 포함될 주체의 일부이며, 일반적으로 인증서의 주체는 신뢰할 수 있는 엔터티(기업, 조직, 개인 등)를 식별하는 데 사용된다. CN은 이 인증서의 식별할 수 있는 식별 값이다.

- server.csr 파일에 서버의 public key와 인증서 요청(Certificate Signing Request)을 저장한다.

- 참고로 쿠버네티스에서 각 컴포넌트들의 CSR에서 CN은 각 컴포넌트의 이름 그 자체이다.

 

 

3. 인증서에 서명 진행 (CA 인증 기관에서 진행)

openssl x509 -req -in server.csr -signkey ca.key

 

- 여기서 서명할 private key(ca.key)가 서버가 자체 생성한 private key라면 Self-Signed 인증서가 된다.

- CA 인증기관에서 인증서에 서명할 때에는 CA 인증 기관의 private key로 서명해준다.

 

 

2) 클라이언트 측

- 클라이언트 측에선 대칭키(key 1개)를 생성하고 이를 서버의 Public key로 암호화한다.

- 일반적으로 key-pair가 아닌 대칭키를 만들 때에는 ssh-keygen 커맨드가 사용된다.

 

ssh-keygen -t rsa -b 2048 -f client.key

위 커맨드는 단순 예시로, 2048비트 RSA 알고리즘을 사용하여 새로운 키를 생성하고, 해당 키를 client.key 파일에 저장한다.

 

openssl rsautl -encrypt -inkey server_public.key -pubin -in client_key.bin -out encrypted_key.bin

그리고 위와 같이 서버의 public key를 기반으로 클라이언트의 대칭키를 암호화한다.

 

- encrypt : 암호화 작업을 지정한다.
- inkey server_public.key : 서버의 공개키(server_public.key)를 지정한다.
- pubin : 공개키 파일을 사용한다는 것을 명시한다.
- in client_key.bin : 클라이언트의 대칭키(client_key.bin)를 암호화할 데이터로 지정한다.
- out encrypted_key.bin : 암호화된 대칭키를 저장할 파일(encrypted_key.bin)을 지정한다.

위의 명령어를 실행하면, 서버의 public key를 사용하여 클라이언트의 대칭키가 암호화되어 encrypted_key.bin 파일에 저장된다. 이 암호화된 대칭키는 서버가 클라이언트와 안전하게 통신하기 위해 사용된다.

 

[참고]

* 사실 이 과정에서 csr 파일(서명 요청 파일)을 만들 때 인증기관을 명시해줘야 한다. (CN 옵션을 사용하여 어떤 인증기관한테 서명을 요청할지 명시 필요)

* 클라이언트는 이 전자 서명이 공인 전자서명인지를 확인해야 하는데, 보통 브라우저는 대부분의 인증 기관의 public key를 가지고 있다. 브라우저는 이 인증 기관의 public key를 기반으로 전자 서명이 공인인지를 확인한다.

* CA 인증은 자체적으로 호스팅 된 서버에 대해 인증을 진행하지 않는다. 이 경우 내부적으로 자체 인증서를 만들고 인증한다. 예를 들면, 사내 급여, 인사 시스템 등이 해당된다. 이때 자체적으로 구성한 CA서버의 public key를 직원들의 브라우저에 설치하도록 하여 인증을 진행하는 방식이다.

* 일반 웹 서비스의 경우 클라이언트에 대한 유효성 검사는 ID, Password로 구성되지만 클라이언트 역시 인증된 클라이언트만 서버가 허용해야 할 경우가 있다.(예를 들면, k8s의 각 구성요소들) 이런 경우에는 마찬가지로 클라이언트도 CA 인증서를 서버에게 보내어 자신이 올바른 클라이언트임을 서버에게 인증한다.

* CA인증서, 서버, 전자서명, 키 생성, 배포, 유지와 같은 전체 프로세스 인프라를 PKI(public key infrastructure)라고 한다.

* 결국 public key는 자물쇠역할을 하게 되는 것이고 private key가 열쇠역할을 하게 되는 셈이다. 즉, 열쇠(private key)는 보내지지 않고 자신만이 갖고 있기 때문에 암호화된 데이터와 public key를 제삼자가 알게 되어도 원본은 알 수 없게 되는 것이 원리이다. 따라서 private key는 유출되지 않도록 주의해야 한다.

* public key가 포함된 인증서 파일은 .crt 또는 .pem 확장자를 가진다.

* private key 파일은 보통 .key 또는 -key.pem(파일명의 마지막에 "-key"를 포함함) 확장자를 가진다. 즉, 파일명에 key라는 단어가 없다면 보통 public key이다.

 

 

---

 

cf. TLS handshake에서 Client Hello 단계의 cypher suites란?

- 클라이언트는 자신이 해독할 수 있는 암호화 알고리즘 리스트를 의미한다.

- cypher suites는 아래와 같이 총 5개만이 존재한다.

 

1) TLS_AES_128_GCM_SHA256

2) TLS_AES_256_GCM_SHA384

3) TLS_CHACHA20_POLY1305_SHA256

4) TLS_AES_128_CCM_SHA256

5) TLS_AES_128_CCM_8_SHA256

 

-> 예를 들어 TLS_AES_128_GCM_SHA256의 의미는 TLS 프로토콜을 사용하고, AES_128_GCM은 사이퍼모드, SHA256은 해싱 알고리즘을 의미한다.

 

[AEAD사이퍼모드]

- AEAD(Authenticated Encryption with Associated Data)는 데이터 암호화 알고리즘

- AES_128_GCM 등이 있음. 이는 128비트 키를 사용하는 표준 블록 암호화와 병렬계산에 용이한 GCM 알고리즘을 결합하여 사용한다는 의미

 

 

cf. 암호화 알고리즘

- 키 교환 암호화 알고리즘에는 대표적으로 '대수곡선 기반 ECDHE'와 '모듈식 기반의 DHE'가 있다.

- 두 알고리즘 모두 '디피-헬만' 방식 기반임.

 

cf. 디피-헬만 키 교환 암호화 알고리즘 (Diffie–Hellman key exchange)

- g와 a와 p를 안다면 A를 구할 수 있지만, g와 A와 p만 안다면 a를 구하기는 어렵다는 원리를 기반으로 만들어졌다.

 

https://rsec.kr/?p=242

 

 

 

---

 

바보 같은 질문은 없다!

1. HTTPS는 HTTP content를 암호화를 하는 게 아니다

- HTTPS는 단순히 TLS 레벨의 공유키(대칭키)를 기반으로 L7 메시지인 'HTTP 메시지 자체'를 인코딩, 디코딩을 하는 것을 의미하며 TLS 통신과는 무관하다. 즉, HTTP와 HTTPS는 L7 단계에서 다를게 하나도 없으며 단순히 L5에서 TLS를 적용하냐, 그렇지 않느냐의 차이일 뿐이다.

- HTTPS는 HTTP 메시지 전체를 암호화한다. 즉, body만 암호화하는 것이 아니다. 이는 TLS가 L5이고 HTTP가 L7이라는 점을 생각해 보면 금방 이해할 수 있다.

 

 

2. 하나의 시스템에서 TLS 통신을 하는 여러 애플리케이션이 있다면? - TLS의 SNI(Server Name Indication)

하나의 머신에서 여러 개의 HTTPS 애플리케이션을 실행하는 경우, 이들은 모두 같은 443 포트를 사용하는데, 이를 가능하게 하는 것은 TLS 프로토콜의 가장 기본적인 특성 중 하나인 "SNI(Server Name Indication)"이다. SNI는 TLS 통신에서 사용되는 클라이언트 측 Hello 메시지의 일부로 전송된다. 이 Hello 메시지는 클라이언트가 접속하려는 서버의 호스트 이름을 나타내며, 이를 통해 서버는 해당 호스트 이름과 연결된 인증서를 제공하게 된다.

따라서 클라이언트가 서버에 연결할 때 Hello 메시지를 보내면, SNI 필드를 포함하여 해당 호스트 이름을 전송한다. 서버는 SNI 필드를 확인하고 해당 호스트 이름에 대한 인증서를 제공한다. 이를 통해 같은 포트를 공유하는 여러 애플리케이션 간에도 인증서를 구분할 수 있다.

또한, 서로 다른 애플리케이션이 모두 443 포트를 사용하더라도 각각의 애플리케이션은 서로 다른 공개키를 가지고 있다. 이는 각각의 인증서가 서로 다른 공개키를 사용하기 때문이다. 즉, 서로 다른 도메인 이름을 사용하는 각각의 애플리케이션은 서로 다른 인증서를 사용하며, 각각의 인증서는 해당 도메인 이름에 대한 공개키를 포함하고 있다. 따라서 클라이언트는 SNI 필드를 통해 요청한 도메인 이름을 식별하고, 해당 도메인 이름에 대한 인증서를 사용하여 암호화된 통신을 수행하게 된다.

 

3. TLS를 기반으로 하는 L7 프로토콜

- HTTPS, FTPS, POP over SSL, SMTPS

 

 

4. SSL 인증서 발급에 호스트 도메인이 필요한 이유

SSL (Secure Sockets Layer) 통신을 하기 위해 도메인이 필요한 이유는 SSL 인증서의 발급과 인증 과정에서 사용된다. SSL 인증서는 서버의 도메인 이름, 즉 호스트 이름에 맞게 발급된다. SSL 인증서는 해당 도메인 이름이 신뢰할 수 있는 것으로 인증되었음을 나타낸다. 이 인증 과정에는 대표적으로는 DNS 인증, 이메일 인증, HTTP 인증 등이 있다. 즉, 해당 도메인 이름의 실제 소유자임을 확인한다. 이를 통해 SSL/TLS 인증서는 도메인 이름의 소유자가 해당 서버에 대한 제어 권한이 있음을 확인하며, 이는 인증된 서버가 실제로 해당 도메인의 소유자가 제어하는 서버임을 보장한다.
 
참고로 Self-Signed Certificate을 사용하면 해당 호스트에서 자체적으로 발급하기 때문에 도메인은 필요 없다. 따라서 로컬 망에서만 사용될 경우(kubernetes api server, 사내 시스템 내부 인증기관에서 인증서를 만들 때)나 테스트용도로 사용할 경우엔 Self-Signed Certificate가 사용된다.

 

 

5. 서버만 인증해야 하나?

- 일반 웹 서비스의 경우 클라이언트에 대한 유효성 검사는 ID, Password로 구성되지만 클라이언트 역시 인증된 클라이언트만 서버가 허용해야 할 경우가 있다. 이런 경우에는 마찬가지로 클라이언트도 CA 인증서를 서버에게 보내어 자신이 올바른 클라이언트임을 서버에게 인증한다.

- 예를 들어 k8s에서 각 구성요소들(etcd, api-server, kubelet, kube-proxy 등)은 각각이 서버로서, 클라이언트로서 동작하게 되는데 클라이언트로서 동작할 때에도 본인을 인증하기 위해 인증서를 사용한다. 이 경우 양쪽에서 서로를 인증하는 과정이 포함된다.

 

 

6. 다중 도메인 호스팅 서버의 CA 인증서

- 하나의 머신에 여러 서버 애플리케이션이 구동되고 하나의 IP에 여러 도메인이 호스팅 되어 있을 경우엔 해당 서버가 여러 인증서를 가질 수 있다.

 

  
7. jwt 토큰, OAuth와 SSL 차이

- JWT는 주로 인증(Authentication)과 권한 부여(Authorization)를 모두 지원하는 기술이지만, 인가(Authorization)에 더 가깝다.

- JWT 토큰은 '애플리케이션 레벨'에서 사용하는 인증 또는 인가 방식 중 하나일 뿐이며 TLS처럼 통신 규약이 아니다.

- TLS는 데이터 암호화 방식, 상대의 인증 방식 등을 포함하는 통신 보안 규약이다.

- 즉, TLS는 통신 보안에 사용되고, JWT는 사용자 인증과 권한 부여에 사용된다.

 

 

 

 

 

 

 

 

Reference

- HTTPS, SSL/TLS 동작방식, https://jh-labs.tistory.com/748
- SSL과 인증서, https://wiki.kldp.org/HOWTO/html/SSL-Certificates-HOWTO/x70.html
- Self-signed certificate, https://en.wikipedia.org/wiki/Self-signed_certificate
- openssl로 Self-signed certificate 생성하기, https://www.baeldung.com/openssl-self-signed-cert
- TCP/TLS handshake 절차, https://www.imperva.com/learn/performance/cdn-and-ssl-tls/
- TLS의 SNI(Server Name Indication), https://ko.wikipedia.org/wiki/%EC%84%9C%EB%B2%84_%EB%84%A4%EC%9E%84_%EC%9D%B8%EB%94%94%EC%BC%80%EC%9D%B4%EC%85%98
- TLS handshake 과정, https://yozm.wishket.com/magazine/detail/1852/
- SSH Connection With Java, https://www.baeldung.com/java-ssh-connection