보안 스터디 - 보안 전송(7/?)

이 장은 많은 인프라담당자와 개발자에게 매우 익숙한 내용이 많이 나온다. 바로 보안 전송 프로토콜에 대한 내용이다. 아마 암호학 부분에서도 실무에 가장 많이 사용되는 부분이 아닌가 싶다. 여기서는 특히 TLS 프로토콜에대해 주로 거론된다.

 

자 그러면 TLS에 대해 이해하기 위해선 아주 간단한 HTTP 프로토콜에 대해 알아볼 필요가 있다. HTTP는 메시지 전송 제어 프로토콜(TCP)에 정의된 TCP 프레임이라는 다른 유형의 메시지로 캡슐화 된다. TCP는 이진 프로토콜이기 때문에 사람이 읽을 수 없다. 

 

자 그렇다면 HTTP 프로토콜을 사용하는 example.com이라는 웹 서버가 있다고 가정해볼때 클라이언트가 해당 서버를 요청하고 응답받고 있다고 하자. 이때 악의적인 사용자가 있다면 MITM 공격을 통해 메시지를 변조하고 재정렬또한 가능하다. 따라서 이런 메시지 전송간 보호를 위해 전송 계층 보안(TLS) 이전의 보안 소켓 계층(Secure Sockets Layer, SSL) 프로토콜이 탄생했다. 그래서 HTTP와 함께 사용되며 HTTPS라는 프로토콜로 우리에게 알려져 왔다.

 

SSL 에서 TLS로

SSL은 이미 많은 곳에서 표준화 되었다. 다만 SSL의 모든 버전(SSL v3.0) 은 잘못된 설계와 알고리즘으로 대부분 뚫렸다. 이건 대부분 RFC7457에 요약 되어 있다. 따라서 SSL3.0 이후 RFC를 담당하는 조직인 IETF에 공식적으로 이관되며 TLS로 대체되었다.

 

실전 TLS

TLS를 사용하기 위해선 클라이언트와 서버가 필요하다. 서버는 TCP/IP를 통해 연결이 가능하다. 

• 설정 : 클라이언트는 지원하는 SSL및 TLS 버전 연결 보안을 위해 알고리즘을 설정한다
• 연결하려는 서버에 대한 정보 : IP주소와 포트가 필요하다. 하지만 웹인 경우 정규화된 도메인이 포함되기도 한다.

이 두가지 조건이 만족되면 암호화된 메시지를 서로 공유하는데 사용 가능한 보안 세션이 생성된다. TLS는 TCP 기반의 동작이므로 UDP는 TLS와 유사한 DTLS를 사용하여 암호화가 가능하다.

TLS 동작 방식

TCP 3-way, 4-way 핸드셰이크와 같이 TLS또한 핸드셰이크를 가지고 있다. 따라서 아래와 같이 두 단계로 나뉜다.

• 핸드셰이크 단계 : 보안 통신을 위해 협의하고 두 참가자간의 보안 통신 세션을 생성한다
• 핸드셰이크 후 단계 : 두 참가자가 암호화 통신을 진행한다.

핸드셰이크의 핵심은 결국 키 교환이다. 두 참가자가 대칭 키 세트에 동의하는 것으로 끝난다. 핸드셰이크는 아래의 네가지 속성으로 또 나뉜다

• 협의 : TLS 설정에 따라 두 피어를 안전하게 연결하기 위해 클라이언트와 서버 구성간의 공통점을 찾는다
• 키 교환 : 핸드셰이크의 핵심은 두 참가자의 키 교환이다
• 인증 : MITM 공격자가 키 교환의 한쪽을 흉내 내는 것은 어렵지 않기 때문에 인증을 통해 키를 인증한다
• 세션 재개 : 브라우저와 통신할때는 서로간의 상호작용이 많기 때문에 세션을 연결하여 키 교환을 다시 하지 않도록 유지한다.

TLS 버전별 키 교환

TLS 1.2 및 이전 버전에서 클라이언트와 서버는 두 참가자가 사용할 키 교환 알고리즘에 동의한 후에만 키 교환을 시작하며 협의 단계에서 이루어 지지만 1.3 버전의 경우 협의와 키 교환을 동시에 시도하여 흐름을 최적화 하였다. 

TLS 인증 및 웹 공개 키 인프라

1. 키 교환 : 이 단계에서는 일보 협의를 제공하고 키 교환을 수행하는 메시지를 포함한다.
2. 서버 파라미터 : 이 단계의 메시지에는 서버의 추가 협의 데이터를 포함한다.
3. 인증 : 이 단계에서는 서버와 클라이언트 모두의 인정 정보를 포함한다.

mTLS
클라이언트 인증은 크레센셜을 묻는 양식을 통해 어플리케이션 계층에 위임되기도 한다. 어떤 의미냐 하면 서버가 요청하는 경우 클라이언트 인증이 TLS에서도 발행할 수 있다. 이렇게 서버와 클라이언트 연결 자체가 모두 인증되면 이것은 상호인증된 TLS(mutually Authenticated TLS, mTLS)라고 한다.

자 그렇다면 공개된 인터넷에서 우리가 키를 교환했다. 그렇다면 예를들어서 amazon.com에 연결할 때 브라우저는 사용자가 실제로 amazon.com과 핸드셰이킹 하는지 어떻게 확인할까? 답은 웹 PKI 이전 포스팅에서 이야기한 PKI를 사용한다.

 

웹에서는 CA라는 인증 기관이 있다. 브라우저는 이 CA라는 루트 공개 키 세트를 신뢰해야 한다. 따라서 하드코딩된 신뢰할 수 있는 공개키 세트를 사용하거나 OS에 등록된 세트에 의존한다.

 

또한  HTTPS를 사용하려는 웹 사이트는 이러한 CA로부터 인증을 얻을 수 있는 방법이 있어야 한다. 따라서 우리는 도메인을 구매하고 도메인 소유자는 해당 도메인 소유주 라는 것은 CA에 증명해야 한다. 물론 이러한 경우 일부 수수료가 발생한다. 다만 최근 Let's Encrypt와 같은 무료 CA 기관이 있기 때문에 어느정도 무료로 사용이 가능하다(물론 인증된 윺효기간을 짧아서 지속적으로 갱신해 주어야 한다)

 

CA는 웹사이트의 공개 키 를 통해 서명을 제공한다 또한 서명은 일반적으로 수년간 유효하기때문에 장기 서명 공개 키 라고도 말한다. 구체적으로 보면 CA는 실제로 공개 키에 서명하지 않고 대신 인증서(certificate)에 서명한다. 이 인증서에는 웹 페이지의 도메인 이름과 같은 몇가지 중요한 추가 메타데이터와 함께 장기 공개 키를 포함한다.

• 도메인 이름(ex: amazon.com) 아마존의 장기 서명 공개 키, CA 서명을 포함하는 자체 리프 인증서
• 아마존 인증서에 서명한 인증서에서 마지막 중간 CA에 서명한 루트 CA까지의 인증서 체인

 

 

다음에는 x.509에 대해 간략하게 알아보겠다.