SSL/TLS

👣 개요

SSL은 초기 버전으로 차후 TLS로 명칭이 변경되었으나 보통 SSL/TLS라고 부른다.
SSL은 Client와 Server가 통신할 때, 제 3자가 도청하지 못하도록 변조를 하는 방법이다.

SSL은 비대칭키와 대칭키를 이용해서 성능적 이점과 보안적 이점 모두를 취한 기술이다.
Http 통신 중에 절대 원문 그대로 정보를 주고 받지 않고 대칭키로 암호화 후에 전송하는 것이 특징이다.
위 방법으로 인해 제 3자가 패킷을 탈취하더라도 알 수 없는 암호로 적혀있어 보안에 유리하다는 특징이 있다.

👣 사전 지식

대칭키는 암호화와 복호화 과정에 사용되는 컴퓨터 자원이 비교적 적고 속도가 빠르다.
하지만 최초에 대칭키를 결정하고 교환하는 과정 중 탈취를 당할 염려가 있어 보안적으로 불안정하다.

비대칭키는 암호화와 복호화 과정 중 사용되는 키가 다르다.
예를 들어 암호화에는 '공개키'를 사용하고 복호화에는 '비밀키'를 사용하는 등의 방법을 사용할 수 있다.
이 때문에 사용자에게 공개키를 전달하고 클라이언트가 암호화하고 서버가 복호화하면 탈취 염려가 없다.
하지만 비대칭키 알고리즘이 비교적 컴퓨터 자원을 많이 소모하기 때문에 적용하기에 부적절한 부분이 있다.

SSL 프로토콜은 이 2 가지의 단점을 보완하고 장점을 살리는 방법을 사용함.
우선 효율적인 암,복호화를 하기 위해 기본적으론 대칭키를 사용한다고 생각하면 된다.
하지만 최초에 대칭키를 결정하고 주고 받는 과정에서 보안 위험이 도사리고 있기에
이런 대칭키 교환 과정에서 비대칭키를 사용한다. 이를 통해 서로의 장단점을 잘 버무렸다고 평가할 수 있다.

👣 대략적 과정

인증서 발급

1. 웹 Application이 CA 라는 공적으로 인증 받은 기관에 인증서를 요구한다.
2. CA 기관에서 심사를 거친 후에 인증 받으면 인증서를 웹 Application에게 전달한다.
이 때, 인증서에는 비대칭키 중 '공개키'를 내포하고 있다.
이는 이 후, 실제 HTTP 소통 중에 사용할 '대칭키'를 암호화할 때, 사용한다.

Client의 서버 검증 - 1 RTT 소모[==왕복 1번]

1. Client가 Server에게 인증서+대칭키를 요구한다.
2. Server가 응답을 하면 Client가 CA 기관의 공개키를 이용해서 Server의 인증서를 복호화해본다.
만약 복호화에 성공하면 위조되지 않은 인증서임을 알 수 있어서 나머지 과정을 수행하면 된다.
만약 복호화에 실패하면 위조된 인증서이므로 과정을 중단한다.

대칭키 교환 - 1 RTT 소모[==왕복 1번]

1. Client가 대칭키를 생성하고 Server의 공개키로 암호화한다.
2. Server가 암호화된 대칭키를 받고 Server의 비밀키로 복호화한다. 따라서 대칭키를 취득하게 된다.

 

👣 CA 등록

TLS Handshake를 시작하기 이전에 서버는 CA에게 신뢰성을 인정받고 
그 증거인 인증서를 받아야 한다.

1. 인증서 요청 [Server -> CA]
서버는 미리 TLS 통신 중 사용할 개인키와 공개키를 미리 만들어 둔다.
Certificate Signing Request를 인증서에 보낸다.
이것은 [서버 도메인정보, 서버 공개키]를 포함하고 있다.

2. 신원 확인 [CA]
CA는 해당 정보들로 서버의 신뢰성을 심사한다.

3. 인증서 발급 [CA -> Server]
CA는 CSR에 있던 각종 정보들[서버 도메인정보, 서버 공개키, ...]을 CA 비밀키로 암호화하고
이것을 Server에게 전달한다. 이것이 인증서다.

👣 TLS Handshake

TCP 3-Way Handshake가 끝나면 시작된다. 해당 과정은 2가지 과정으로 나뉜다.
각 과정은 1 RTT씩 소비한다.
사용할 암호 알고리즘 합의 / 사용할 대칭키 합의

그리고 각 비대칭키의 역할을 분명히 해야 한다.

	CA 비밀키	CA 공개키	Server 비밀키	Server 공개키
Role	인증서 암호화	인증서 복호화	대칭키 복호화	대칭키 암호화

1. Client Hello [Client -> Server]
사용하고 싶은 TLS 버전, 여러 개의 암호 알고리즘 전달

ClientHello {
    ProtocolVersion: TLS 1.2
    SupportedCipherSuites: [TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA256]
    Random: [4e 5f b0 8e ...]
    ...
}

2. Server Hello [Server -> Client]
앞으로 사용할 TLS 버전, 여러 개의 암호 알고리즘 전달

ServerHello {
    ProtocolVersion: TLS 1.2
    CipherSuite: TLS_RSA_WITH_AES_128_CBC_SHA256
    Random: [2a a1 79 41 ...]
    ...
}

3. Certificate [Server -> Client]
서버 인증서를 전달함.
여기에 공개키가 포함되어 있음.

Certificate {
    CertificateData: [서버 인증서 데이터]
    ...
}

4. ServerHelloDone [Server -> Client]
ServerHello 종료를 전달함.

5. ClientKeyExchange [Client -> Server]
CA 공개키[이미 Client는 CA 공개키 보유]로 서버 인증서를 복호화함.
복호화가 성공하면 서버의 신뢰성이 확보됨.
Client -> Server로 대칭 키 생성 후 서버 공개키로 암호화 후 전송.

ClientKeyExchange {
    PreMasterSecret: [클라이언트에서 생성한 임시 키]
    ...
}

6. ChangeCipherSpec / Finished
먼저 Client -> Server로 여태까지 주고 받았던 패킷을 생성한 대칭 키로 암호화하고 상대방에게 전송함.
그리고 Finished 신호를 전송.

그 다음 서버에서 주고 받았던 패킷을 복호화해보고 내용이 일치한다면 무결성이 지켜짐을 알 수 있게 된다.
Server -> Client로 여태까지 주고 받았던 패킷을 생성한 대칭 키로 복호화하고 상대방에게 전송함.
그리고 Finished 신호를 전송.

총 3 RTT가 소비됨.