네트워크 보안 - 프로토콜 - SSL/TLS

SSL이란

SSL은 보안 소켓 계층(Secure Sockets Layer)의 약자다. 1990년대 중반 당시 가장 널리 사용되던 웹 브라우저를 만든 넷스케이프(Netscape)에서 개발한 프로토콜의 원래 이름이었다. SSL 1.0은 일반에 공개된 적이 없고 SSL 2.0에는 심각한 결함이 있었다. 1996년에 공개된 SSL 3.0은 전면적으로 수정돼 다음 버전이 나올 수 있는 기반을 마련했다.

 

TLS란

1999년 공개된 차기 버전 프로토콜은 국제 인터넷 표준화 기구(IETF)에 의해 표준화되고 전송 계층 보안(Transport Layer Security)의 약자인 TLS라는 새로운 이름을 얻었다. TLS 사양서에 명시된 것처럼 TLS와 SSL 3.0 사이의 차이점은 그다지 크지 않다. 따라서 TLS와 SSL은 별개의 비교 대상으로 취급되지 않는다. 지속적으로 업데이트 되는 일련의 프로토콜을 형성해 'SSL/TLS'로 뭉뚱그리는 경우가 많다.

 

TLS 프로토콜은 모든 종류의 인터넷 트래픽을 암호화한다. 예를 들어 웹 트래픽이라면, 브라우저 상의 주소 URL이 “https”로 시작하면 TLS를 통해 연결된 것이다. 또한 자물쇠 표시는 연결이 안전함을 나타낸다. TLS는 인터넷 이외에 이메일, 유즈넷(Usenet) 등에서도 사용할 수 있다.

 

TLS의 작동 방식

인터넷을 통해 안전하게 통신하려면 암호화가 필요하다. 만일 데이터가 암호화되지 않으면 누구나 패킷을 들여다 보고 기밀 정보를 읽을 수 있다. 가장 안전한 암호화 방법은 ‘비대칭 암호화’다. 제대로 작동하려면 2개의 암호 키(대개 엄청나게 큰 숫자로 이루어졌다)가 필요하다. 하나는 공용 키이고 다른 하나는 개인 키다.

 

여기에 관련된 수학 개념은 복잡한데 간단히 말하면 공용 키는 데이터 ‘암호화’에 사용되고 ‘복호화’하에는 개인 키가 필요하다. 2개의 키는 무작위 시도로는 역엔지니어링하기 어려운 복잡한 수학 공식에 의해 서로 연결돼 있다. 비유하자면 공용 키는 전면에 넣을 수 있는 구멍이 있는 잠겨진 우편함에 대한 정보이고 개인 키는 그 우편함을 열 수 있는 키라고 생각하면 된다. 우편함의 장소를 아는 사람이라면 누구나 메시지를 안에 넣을 수 있지만 누군가 그 메시지를 읽으려면 개인 키가 필요하다.

 

비대칭 암호화에는 이와 같은 어려운 문제가 수반되기 때문에 컴퓨팅 자원이 많이 소요된다. 통신 세션에서 모든 정보를 암호화하면 감당이 안돼 컴퓨터와 연결이 서서히 중단될 정도이다. TLS는 이 문제를 해결하기 위해 통신 세션이 맨 처음 시작할 때만 비대칭 암호화를 사용한다. 그 이후부터는 패킷 암호화에 서버와 클라이언트가 사용할 하나의 ‘세션 키’에 합의하기 위해 양쪽이 나누는 대화를 암호화하는 것이다. 공유된 키를 사용하는 암호화를 ‘대칭 암호화’라고 한다. 비대칭 암호화에 비해 컴퓨터 자원 소모가 덜하다. 해당 세션 키는 비대칭 암호 작성 방식을 이용해 설정되었기 때문에 그렇지 않은 경우에 비해 통신 세션 전체가 훨씬 더 안전하다.

 

해당 세션 키가 합의되는 프로세스의 명칭은 악수를 의미하는 핸드셰이크(handshake)이다. 2대의 통신 컴퓨터가 서로 소개하는 순간이기 때문이다. 핸드셰이크는 TLS 프로토콜의 핵심이다.

 

TLS 1.2와 그 취약성

TLS 1.2는 가장 최신 프로토콜 규정이지만 나온 지 몇 년 됐다. TLS 1.2 덕분에 통신에 사용할 수 있는 새로운 암호화 옵션이 많이 늘었다. 그러나 프로토콜의 일부 이전 버전과 마찬가지로, 구형 컴퓨터 지원을 위해 구형 암호화 기술을 지원하는 과정에서 취약점에 노출되고 말았다. 시간이 지날수록 컴퓨팅 자원이 저렴해지고 있고 구형 기술이 더 취약해진 것이다.

 

특히, TLS 1.2는 소위 '중간자(MITM)' 공격이라는 것에 약점을 갖고 있다. 중간자 공격이란 해커가 통신 중 패킷을 가로채 읽거나 변경한 후에 전송하는 행위를 말한다. TLS 1.2는 POODLE, SLOTH, DROWN 공격에도 노출돼 있다. 이들 문제 가운데 많은 수는 지난 2년 동안에 발견된 프로토콜 업데이트에 대한 요구가 커지고 있다.

 

TLS 1.3

다행히도 구원자가 조만간 등장할 것으로 보인다. TLS 프로토콜 버전 1.3은 현재 초안 형태지만 곧 확정될 예정이다. 그러면 구형 암호 시스템에 대한 지원을 중단해 현재의 많은 보안 취약점을 해결할 수 있다. 만일 어느 한 쪽이 1.3 승인 목록 상의 신형 암호화 시스템을 사용할 수 없다면 연결에 다시 TLS 1.2이 사용된다. 이른바 하위 호환성이다. 그러나 중간자 공격이 패킷 염탐을 위해 강제로 1.2를 사용하려고 시도하면 이는 탐지돼 연결이 중단된다.

 

1.2보다 구형인 TLS 버전을 사용 중인 서버가 아직 많다. 원조 SSL 프로토콜을 사용하는 서버도 있다. 이러한 서버는 당장 업그레이드하되 중간은 건너뛰고 초안 1.3 사양으로 업그레이드하는 것이 좋다.

 

(https://kinsta.com/blog/tls-1-3/

An Overview of TLS 1.3 - Faster and More Secure

 

1. 데이터통신 기밀성 확보 SSL 의 개요

- SSL :보안 소켓 계층을 명시하며, 인터넷상에서 데이터를 안전하게 전송하기 위한 암호화 통신 프로토콜

- SSL 1.0 , SSL 2.0의 보안 취약점으로 SSL 3.0에 와서 IETF 에서 표준화 하여 TLS 1.0으로 릴리즈 함

- 진화 과정

 

- 프로토콜 

 

28번째 초안, 최종 표준으로 통과...구글 등은 이미 적용 시작

호환성과 보안, 퍼포먼스 고려해 미리 시험 기간 거쳐야

 

국제인터넷표준화기구(Internet Engineering Task Force, IETF) 산하 네트워크 워킹 그룹(Network Working Group)이 TLS 1.3에 대한 28번째 초안이 최종 표준으로 통과

 

새로운 표준을 도입하려면 조직들은 세 가지 중요한 사안에 집중해야 한다.

 

1) 0-RTT라고 알려진 ‘제로 라운드 트립 타임’을 어떻게 적용할 것인가?

2) TLS 1.2 다운그레이드

3) 인프라 및 애플리케이션 실험의 필요성

 

 

라운드 트립?

 

TLS 1.3 버전에서 가장 많이 다뤄지는 주제 중 하나가 바로 0-RTT 옵션이다. 엔드포인트 간 암호화된 세션이 진행될 때 속도를 크게 향상시켜주는 것이다. 사실 TLS 1.3 버전은 핸드셰이크 프로토콜이 이전보다 간소화 되어 있어, 0-RTT 없이도 클라이언트와 서버 간 통신 속도가 높다.

 

 

TLS 1.2 버전으로 웹 통신을 보호하는 경우, 클라이언트와 서버 간 두 번 왕복(round trip)을 해야 클라이언트가 HTTP 요청을 서버로 보내고, 서버가 그에 대한 응답을 보낼 수 있었다. 하지만 TLS 1.3에서는 이를 한 번의 왕복으로 줄여준다. 또한 클라이언트와 서버 간 신뢰가 형성될 경우 왕복의 필요성이 0으로 줄어든다. 그게 바로 0-RTT다.

 

 

0-RTT 옵션은 보안보다는 퍼포먼스를 위한 옵션이다. 그렇기 때문에 보안 구멍으로 비춰지기도 한다. 라운드 트립이 하나도 없는 환경에서는 어떠한 거래라도 쉬운 목표물이 될 수 있다. 공격자들은 암호화된 클라이언트 메시지를 가로채고 이를 다시 서버로 자기들이 임의로 전송할 수 있게 된다. 그럼으로써 서버의 ‘신뢰’ 구조를 자신들에게 유리하게 작동시키는 것이다.

 

 

그러니 TLS 1.3을 도입해야 하는 각 조직은 0-RTT의 이러한 위험성을 이해하고, 인터넷을 통해 제공하는 서비스와 애플리케이션들을 먼저 손봐야 한다. 개발자들이 특히 이 문제에 민감하게 반응해야 하는데, 0-RTT의 안전한 도입을 위해서는 능동적인 보안 점검 및 실험이 필요하기 때문이다. 속도가 대단히 민감한 부분이 아니라면 0-RTT 옵션은 비활성화시키는 것도 나쁘지 않은 선택이다.

 

 

다운그레이드

 

TLS 1.3 버전의 가장 큰 장점 중 하나는 오래된 암호화 표준이나 솔루션을 더 이상 지원하지 않는다는 것이다. 하지만 TLS 1.2로의 하위 호환은 가능하게 만들어준다. 물론 표준을 바꾼다고 했을 때 호환성 문제 때문에 이전 버전에 대한 지원을 유지하는 건 필수적인 일이다. 그러나 호환성에서 문제가 발생했다고 해서 곧바로 TLS 1.2로 다운그레이드 하기 보다는, 다른 환경설정부터 먼저 점검해야 한다. 다운그레이드는 정말 최후의 최후까지 가서 써볼 수 있는, 어쩔 수 없을 때 꺼내야 하는 카드일뿐이다.

 

 

그리고 다운그레이드를 했다고 해서 TLS 1.2에 머물러서는 안 된다. 거기서부터 암호화 알고리즘이나 솔루션을 보다 더 강력하고, 1.3 버전과 호환이 되는 것과 차근차근 바꿔나가야 한다. 그래서 결국에는 TLS 1.3으로 되돌아오는 것이 필요하다. 강력한 암호화 알고리즘이란 타원 곡선 암호 키 교환이나 대형 비대칭 키 방식 등을 말한다. 또한 완전 순방향 비밀성도 도입해야 한다.

 

(http://www.boannews.com/media/view.asp?idx=70957&kind=0

바짝 다가온 TLS v1.3, 도입 전에 고려해야 할 것 3

 

TLS 크라임웨어

TLS과 보안에 관해 마지막으로 주의를 당부할 것은 착한 사람들만 TLS를 사용하는 것은 아니라는 점이다! 많은 사이버 범죄자가 희생자의 컴퓨터에 악성코드를 설치한 후 자신들 서버와의 명령 통제(C&C) 트래픽 암호화에 TLS를 사용한다. 그러면 보통의 상태가 뒤집혀 버리기 때문에 사이버 범죄 희생자는 트래픽 복호화 방법을 찾아 나서게 된다.

 

이런 종류의 암호화 공격에 대처할 수 있는 기법이 여러가지 있다. 예를 들면, 암호화된 트래픽에 관한 네트워크 메타데이터를 사용해 암호화된 트래픽을 실제로 읽지 않고도 공격자가 무엇을 하고 있는지 감을 잡을 수 있다.

 

(http://www.ciokorea.com/news/36923

'웹 보안의 시작' TLS의 정의와 1.3 업그레이드가 시급한 이유