티스토리 뷰

TLS 는 SSL 과 같은 의미이여 TCP 통신에서 오고가는 데이터를 암호화하기 위한 프로토콜이다.

TLS 과정

인증서 발급

 TLS 인증을 하고자하는 서버가 CA (Certifiacate Authorities : 인증서 발급 기관) 로부터 인증서를 발급 받는다.

  1. Server 는 공개키/비공개키를 생성하고 인증서 신청시 공개키를 CA 에 전달
  2. CA 는 인증서에 Server 의 공개키를 포함하여 인증서를 생성
  3. CA 는 인증서 내용을 Hash 처리한 값을 CA 의 비밀키로 암호화하여 인증서에 포함

TLS 연결

Client 와 Server 가 HTTP Handshake 이후에 TLS 인증 절차를 거친다.

  1. Client 는 Server 에게 ssl 버전, 사용 가능한 암호화 프로토콜등을 전달한다.
  2. Server 는 Client 에게 사용할 암호화 프로토콜과 암호화된 SSL 인증서를 전달한다.
  3. 인증서를 받은 Client 는 CA List 에서 CA 공개키를 찾아 인증서 내의 암호화된 Hash 값을 복호화
    • 신뢰할 수 있는 CA List 의 공개키로 복호화에 성공했다는 것은 CA 의 비밀키로 암호화된 인증서라는 것을 뜻하며 CA 로 부터 발급된 인증서라고 판단할 수 있다.
    • 복호화한 Hash 값과 Client 가 받은 인증서를 Hash 처리한 값이 동일하다면 Server 로 부터 받은 인증서는 CA 가 발급할때와 동일하며 변조되지 않았다고 판단할 수 있다.
  4. 인증서 내의 Server 의 공개키 획득
  5. Client 는 대칭키를 생성하여 SSL 인증서 복호화 후에 획득한 Server 의 공개키로 암호화하여 서버에게 전달한다. (premaster secret key)
  6. premaster secret key 를 받은 서버는 Server 의 비공개키로 복호화하여 대칭키를 획득한다.
  7. Client/Server 모두 같은 대칭키를 갖게되어 대칭키로 암호화/복호화하여 통신한다.

 

Java TrustStore, KeyStore

Java 에서 TLS 통신을 위해서 jdk 의 TrustStore 와 KeyStore 를 사용할 수 있다.

  • TrustStore : 신뢰할 수 있는 CA List
  • KeyStore : 비밀키, 암호화된 SSL 인증서

TrustStore 는 Client 측에서 사용되고 KeyStore 는 Server 측에서 사용된다.

 

1 Way SSL vs 2 Way SSL

 위에서 설명한 방식은 1 Way SSL 방식이며 Client 의 인증서를 Server 가 Verify 하게 되면 2 Way SSL 이 된다.

 

Architecture

  • SSL Termination
    • L7 LoadBalancer 에서 Client 와 LB 간의 HTTPS 통신을 하고 복호화한 데이터 기반으로 LB 와 Server 간에는 HTTP 통신
      • LB 가 HTTPS 암호화/복호화를 담당하여 Server 는 암호화/복호화의 부하를 받지 않음
      • LB <-> Server 간에는 HTTP 통신을 하므로 보안 취약점 노출
  • SSL Throughpass
    • LB 는 HTTPS 복호화를 하지 않고 암호화된 데이터는 Server 까지 전달됨
  • SSL Bridging
    • LB 에서 복호화한 후에 LB <-> Server 는 새로운 SSL connection 을 맺음

 

Chaining Certificate

 새로운 인증서가 발급될때마다 Client 가 해당 인증서를 CA List 에 갖지 않고 있어도 신뢰할 수 있는 인증서로 판단할 수 있는건 Chaining Certificate 로 설명할 수 있다.

 

  • ROOT CA :  최상위 인증서 발급 기관. Root CA 업체는 매우 제한적이며 Root CA 인증서는 모든 Client 가 가지고 있다.
  • Intermediate CA : 중간 인증서 발급 기관. Intermedicate CA 는 Root CA 로 부터 인증서를 발급 받으며 Server 에게 인증서를 발급해준다. Intermediate 의 인증서에는 Intermediate 의 공개키가 포함되어있다.
  • Server : 최종적으로 인증서를 발급 받고자 하는 서버. Intermediate CA 에게 인증서 발급 받는다. Intermediate CA 에게서 발급받은 인증서에는 Server 의 공개키가 포함되어있으며 서명 목록에는 ROOT CA, Intermdiate CA, Server 로 작성된다.

인증서 발급 과정

  1. Intermediate CA 가 Root CA 에게 인증서 발급 신청
    • 발급받을 인증서에 포함될 Intermdiate CA 의 공개키 전달
  2. Root CA 는 Root CA 의 비밀키로 Intermediate CA 에게 발급해주는 인증서의 Hash 값을 Root CA 의 비밀키로 암호화하여 인증서에 포함.
  3. Server 가 Intermediate CA 에게 인증서 발급 신청
    • 발급받을 인증서에 포함될 Server 의 공개키 전달
  4. Intermediate CA 는 Server 에게 발급해주는 인증서의 Hash 값을 Intermediate CA 의 비밀키로 암호화하여 인증서에 포함.

인증 과정

  1. Client 는 서명목록을 보고 Server 로 부터 받은 인증서에서 Server Cert 를 발급한 Intermdeiate Cert 획득
  2. Client 는 서명목록을 보고 Intermediate Cert 를 발급한 Root CA Cert 확인
  3. Root CA 의 Cert 는 모든 Client 가 가지고 있다.
  4. Intermediate Cert 의 Hash 는 Root CA 의 비밀키로 암호화되어 있으므로 Client 가 가지고 있는 공개키로 복호화 가능
  5. 복호화에 성공하고 Intermeidate Cert 를 hash 한 값과 동일하다면 Intermediate Cert 검증에 성공
  6. Server Cert 는 Intermediate CA 에서 발급하였으므로 Server Cert 의 Hash 값은 Intermediate CA 의 비밀키로 암호화되어있음
  7. Client 는 Intermediate Cert 에 포함된 Intermediate 공개키로 Server Cert 의 hash 값을 복호화
  8. 복호화에 성공하고 복호화된 값이 Server Cert 를 hash 한 값과 동일하다면 검증에 성공
  9. Client 는 Server Cert 에 포함된 공개키로 대칭키를 암호화하여 Server 에게 전달.
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
글 보관함