'상태유지 프로토콜'에 해당되는 글 1건

SSL(Secure Socket Layer)

SSL은 1994년 netscape사의 웹 브라우저 보안 프로토콜로 처음 고안되어 1996년까지 버전 3.0까지 발표되었는데, 3.0을 표준화한 것이 TLS라고 합니다. 통상적으로 SSL과 TLS는 같은 의미로 사용됩니다.

SSL은 왜 생겨났을까요? 

아마 암호화를 배우신 분이라면 대칭키 암호, 비대칭키 암호를 배우셨을텐데, 대칭키는 빠른 대신 서로간의 공통적으로 알고 있는 키를 공유해야합니다. 대칭적이죠? 그래서 대칭키 암호입니다. 비대칭키는 비대칭적으로 서로 다른 키를 갖고 있어 암복호화를 합니다. 

대칭키암호와 비대칭키 암호에 관한 설명은 지난 포스팅을 참고해주세요.

우리는 대칭키를 공유할때 외부로의 노출이 발생하게 됩니다. 이 키를 중간에서 가로채게 된다면? 망하는거지요. 

그렇다면 대칭키는 우리들 머릿속에서 지워버리고 비대칭키로 암호화 통신을 하면 되겠군요. 가능할 수는 있지만 너무 느리고 비효율적입니다. 

그렇다면 처음 대칭키를 교환할때만 비대칭키 암호를 사용하면 어떨까요? 바로 TLS가 그런 역할을 합니다.

TLS에서 제공하는 보안 서비스

1. 기밀성 (이거 북한 어떤 개랑 발음이 똑같네요)

- 대칭키 암호를 사용하게 되면 기밀성을 제공할 수 있습니다. 남들이 데이터를 훔쳐가도 볼 수 없는 비밀을 제공합니다. 

2. 무결성

- 메시지 인증 코드(MAC: Message Authentication Code)를 통해서 메시지 인증을 제공합니다. 위, 변조 여부를 확인할 수 있지요.

3. 인증

- 연결 초기 설정에서 주고 받는 인증서를 통해서 신뢰할 수 있는 개체인지 인증할 수 있습니다.

TLS는 전송 계층 위에서 TLS 계층을 따로 두어 동작하게 됩니다. TLS를 사용하는 어플리케이션 프로토콜은 끝에 s가 붙게 되는데 TLS기반의 HTTP는 HTTPS라고 지칭합니다. TLS기반의 FTP는 역시 FTPS라고 부르지요. 

TLS의 세부 프로토콜은 다음과 같습니다.

상태 유지(Stateful) 프로토콜 

TLS는 세션과 연결별로 상태정보를 유지합니다. TLS는 Full Handshake를 통해서 세션을 생성하고 이 세션 정보를 공유하는 여러 연결을 Abbreviation Handshake를 통해서 성립합니다. 

Full Handshake는 아래에 그림과 같이 설명합니다. Abbrevation Handshake는 세션이 이미 존재할때 사용하는 Handshake방식입니다. 

용어가 조금 혼동이 될 수 있는데 연결은 서버와 클라이언트 간 통신의 단위를 말하여 세션은 그 연결의 다수로 이루어지며 세션은 한번 성립되면 다음 연결을 위해서 상태를 유지(session id, negotiated cryptography parameters 등)할 수 있습니다. 예를 들면, 이미 한번의 연결을 하여 암호화 방식, 인증서 교환, session id를 공유했고 할 일이 모두 끝나 연결을 끊었습니다. 이 후 다음 연결에 이 세션에 대한 정보를 이용하여 별도의 번거로운 과정없이 연결을 할 수 있는 겁니다.

Handshake

Client → Server : ■

Client ← Server : ■

1) Client Hello (Client 안녕)

Client가 서버에 접속할때 몇가지 데이터를 주는데 첫 인사치고는 조금 깁니다. 무엇이 있나 보도록할까요?

- random : 클라이언트는 32바이트 난수값을 전달합니다. 이 랜덤값은 나중에 비밀 데이터를 위해 사용이 됩니다. 비밀 데이터를 master secret이라고 합니다.

- session ID : 세션을 처음 생성할때는 빈값, 이미 생성된 세션이 있다면 그 세션 ID를 전달합니다. 

- cipher suite : 클라이언트가 지원가능한 키 교환 알고리즘, 대칭키 암호 알고리즘, 해시 알고리즘 등을 알려줍니다. 클라이언트와 서버 사이에 갖고 있는 알고리즘이 다 다르겠죠? 그래서 서버는 이 중에 최적의 방식을 선택합니다. 

EX) TLS_RSA_WITH_AES_128_GCM_SHA256 : 보통 이런식인데, 키 교환 알고리즘은 RSA, 대칭키 알고리즘은 AES_128 GCM방식을 사용하고 Hash 알고리즘으로는 SHA256을 사용한다는 것입니다.

2) Server Hello (Server 안녕)

사용할 TLS버전, 클라이트, 서버 공통으로 지원가능한 최적의 Cihper suite, 압축 방식 등을 client에게 전달합니다. 이 밖에도 다음 정보를 전달하는데요.

- random : 역시 server도 32바이트 난수를 생성해서 client에게 전달합니다. 역시 나중에 master secret이라는 비밀값을 생성할때 사용되는 재료입니다.

- session ID : 세션 정보를 보냅니다.

3) Server certificate

아까 TLS가 인증(TLS의 보안 서비스 3가지 : 기밀성, 무결성, 인증) 서비스를 제공한다고 했습니다. 이 인증서를 이용해서 클라이언트는 서버가 믿을 만한, 신뢰할 만한 서버인지 확인합니다.

4) Server key exchange

키 교환에 필요한 정보를 제공합니다. 만약 필요하지 않으면 이 과정은 생략이 가능한데, 예를 들어 키교환 알고리즘을 Diffie-Hellman으로 사용한다면 소수, 원시근 등이 필요하므로 이것을 전송합니다.

5) Certificate request

서버 역시 클라이언트를 인증해야할때 인증서를 요구할 수 있습니다. 요청하지 않을 수도 있습니다.

6) Server hello done

서버의 인사가 끝났네요. 

7) Certificate 

방금 전 서버가 요청했던 인증서를 줄 수 있습니다. 요청하지 않았으면 필요없는 과정이네요.

8) Client key exchange

키교환에 필요한 정보를 서버에 제공합니다.  이 정보를 pre-master secret이라고 하는데 이게 대칭키에 사용되는 것으로 절대 노출이 되어서는 안됩니다. pre-master secret은 이전에 서버로부터 받은 랜덤값 있었죠? 이것과 클라이언트가 생성한 랜덤값을 조합하여 서버에게 전송합니다. 그냥 보낼까요? 아니죠. 이렇게 민감한 정보는 암호화를 해서 보내야하는데 어떻게 암호화를 할까요? 

이전에 우리는 인증서를 받았습니다. 인증서 안에는 서버의 공개키가 있습니다. 이것으로 서버에게 암호화하여 전송합니다. 

클라이언트는 자기가 생성했으니 이미 가지고 있고, 서버가 무사히 암호화된 pre-master secret을 받았다면 자신의 개인키로 복호화할 수 있습니다. 이제 서로가 pre-master secret을 공유하고 있지요? 이 pre-master secret을 일련의 과정을 거쳐 client/server는 master secret으로 만들게 됩니다.

클라이언트, 서버는 master secret으로 세션에 사용될 키를 생성하게 되는데, 이 키가 바로 대칭키입니다.

9) Certificate verify

클라이언트에 대한 Certificate request를 받았다면 보낸 인증서에 대한 개인키를 가지고 있다는 것을 증명합니다. handshake과정에서 주고 받은 메시지 + master secret을 조합한 hash값에 개인키로 디지털 서명하여 전송합니다.

10) Change cipher spec

협상된 보안 파라미터를 적용하거나 변경될때 서버에게 알립니다.

11) Finished

클라이언트 끝

12) Change cipher spec

클라이언트에게 보안 파라미터 변경을 알립니다.

13) Finished

서버도 끝

14) 통신

이제 주고받은 비밀키를 통해서 안전하게 통신하면 됩니다.

이상으로 TLS에 대한 기본적인 개념과 연결과정을 알아보았습니다.