[webDev] SSL/TLS 프로토콜

목차

 

1. SSL/TLS 란?

2. 주요 차이점

3. SSL의 취약점

4. 결론

위의 목차를 클릭하면 해당 글로 자동 이동 합니다.

 

SSL/TLS 란?

SSL/TLS 인증서는 웹사이트와 사용자가 안전하게 통신할 수 있도록 하는 디지털 문서입니다. 이는 웹 사이트의 신원을 확인하는 용도로 쓰입니다.

 

SSL(Secure Sockets Layer) 은 초기 보안 프로토콜입니다. 옛날에 사용하던 자물쇠로 볼 수 있죠. 하지만 시간이 지나면서 해커들이 이를 쉽게 여는 방법을 찾아 더 이상 사용되지 않고 있으며, 이를 대체하기 위해 나온 것이 TLS (Transport Layer Security) 입니다. 

 

SSL은 원래 Netscape가 개발한 프로토콜이며, TLS는 SSL의 후속 버전으로 IETF(Internet Engineering Task Force)에 의해 표준화되었습니다. SSL v1/2/3까지 존재하며 이후 TLS로 변경되었으며 TLS 1.0/1.1/1.2/1.3의 버전이 존재 합니다. 다만, 초기의 TLS는 기존 SSL의 취약점을 유사하게 가지고 있기에, 현재 대부분의 사이트에서는 TLS 1.0/1.1의 지원이 중단되었습니다. 현재 많이 쓰이는 버전으로는 TLS 1.2 와 1.3 버전입니다. 

* 표준 명칭은 TLS 이지만, 많은 사람들이 이를 SSL과 혼용하여 사용합니다. 

 

주요 차이점

주요 차이점은 다음의 표로 알아 볼 수 있습니다. 특히 SSL 과 TLS의 핸드셰이크 부분을 주목해야 합니다. 

 

SSL의 경우 명시적인 핸드셰이크를 사용하며 이는 암호화 연결을 시작하기 전에 클라이언트와 서버가 명확하게 핸드셰이크를 통해 보안 매개변수를 협상하는 과정을 거치게 됩니다. 반대로, TLS의 경우 암묵적인 핸드셰이크를 사용합니다. 

또한 TLS 에서는 기존 SSL의 핸드셰이크 단계를 축소화하고 총 암호 그룹 수를 줄여 프로세스 속도를 높였습니다. 

 

주요 차이점

 

SSL의 명시적 방식과 TLS의 암묵적 핸드셰이크

SSL의 주요 취약점

SSL의 몇 가지 심각한 보안 취약점에 의해 현재는 사용하지 않습니다. 

 

이러한 취약점은 클라이언트-서버 통신에서의 하위 호환성 문제와 연관성이 높습니다. 하위 호완성이란, SSL/TLS 프로토콜은 보안 연결을 수립할 때 클라이언트와 서버 중 어느 하나라도 최신 버전을 지원하지 않으면 낮은 버전으로 재시도하는 특성이 있습니다. 예를 들어, 클라이언트가 의도적으로 SSL 3.0 사용을 유도하여, 서버가 상위 버전을 사용 하더라도 취약한 버전으로 응답하도록 강제할 수 있는 것이죠. TLS 내에서도 하위 호환성은 가능하지만, 최신 TLS 버전에는 Downgrade Attack 방지 기능이 있어, 취약한 TLS 1.0, TLS 1.1 버전으로 강제 다운그레이드되지 않도록 방어합니다. 

 

MiTM 중 Downgrade Attack 과정

 

SSL에서의 심각한 보안 취약점을 간단하게 알아 봅시다. 복잡한 과정을 최대한 간단하게 표현하기 위함으로, 공격 과정의 많은 생략이 들어가있을 수 있습니다. 

1. POODLE 공격 (Padding Oracle On Downgraded Legacy Encryption)

이 취약점은 구글의 보안 전문가들이 2014년에 SSL 3.0의 설계상 취약점을 활용한 공격을 발표하며 알려지게 되었습니다. 이를 활용하여 해커는 사용자의 비밀번호, 쿠키, 개인정보 등을 탈취할 수 있는 심각한 취약점입니다. 

 

구체적으로 : 

1. 공격자는 클라이언트로서 서버에 요청을 보내고 암호화된 데이터를 얻습니다. 
2. 공격자는 클라이언트의 데이터를 가로채 암호화 데이터 중 패딩을 변조합니다. 이는 서버에 패딩 오류를 유도해 서버의 반응을 관찰하기 위함입니다. (* 패딩은 데이터를 암호화할 때, 데이터의 길이가 일정한 블록 크기에 맞지 않으면 빈 공간을 채워야 하며, 이 때 남는 부분을 패딩으로 채웁니다.)
3. 서버는 패딩 오류를 반환합니다. 
4. 공격자는 패딩 오라클을 활용해 암호화된 데이터를 복호화합니다. 
5. 2-4번을 반복하여 올바른 패딩을 찾고, 데이터를 1 바이트씩 해독합니다. 

실제 클라이언트 A씨가 서버에 민감한 정보 (본인의 개인정보)를 요청합니다. 공격자는 그 암호화된 데이터를 가로채서 5번에서 알아낸 복호화 방법으로 한 바이트씩 정보를 추출합니다. 다만, 정보 추출이 한 바이트씩 이루어지기 때문에 서버와 클라이언트 간의 통신을 가로채는 것을 들키지 않고 지속적으로 관찰하는 것이 중요합니다. 

 

https://security.googleblog.com/2014/10/this-poodle-bites-exploiting-ssl-30.html

This POODLE bites: exploiting the SSL 3.0 fallback

 

2. BEAST (Browser Exploit Against SSL/TLS) 공격

TLS 1.0과 SSL 3.0에서 **고정된 초기화 벡터(IV)**를 사용하는 방식의 취약점을 악용한 공격입니다. CBC (Cipher Block Chaining)모드에서는 각 암호화 블록이 이전 블록과 연결되어 암호화되기 때문에, 공격자는 고정된 IV 값을 예측할 수 있습니다. 이를 통해 클라이언트와 서버 간의 암호화된 데이터를 가로채고, 암호화된 내용을 복호화하여 민감한 정보를 탈취할 수 있는 취약점입니다.

 

구체적으로 : 

1. 공격자는 클라이언트와 서버 간의 세션을 가로챕니다. 세션에는 IV 값과 암호화된 응답을 알아낼 수 있습니다. 
2. 공격자는 IV 값을 하나씩 변경해 서버에 요청을 반복적으로 보냅니다. 
3. 서버가 정상적인 응답을 하면, 공격자는 해당 비트가 올바른지 판단할 수 있습니다. 
4. 이 과정을 반복하면서 각 바이트가 올바르게 복호화 될때까지 시도합니다. 

초기화 벡터(IV)는 암호화 알고리즘에서 첫 번째 블록을 암호화할 때 사용하는 무작위 값 입니다. CBC모드는 각 블록을 이전 블록과 XOR 연산을 통해 암호화 하는데, 첫 번째 블록은 이전 블록이 없기 때문에 IV를 사용해 암호화 합니다. 이후 각 메세지는 이전 암호화 블록의 마지막 값을 IV로 사용합니다. 이 내용은 이해하기 어렵기에, 최대한 간소화하여 예시를 추가적으로 들어봅시다. 

---

상황 

사용자는 b라는 비밀번호로 인증을 합니다. 서버는 b라는 비밀번호의 입력을 받으면 인증을 처리하고, "OK" 메세지를 반환합니다. 

• 사용자의 입력 값 (b) : 01100010 (b의 2진수 값)
• IV (초기화 벡터) : 10101010 (랜덤 생성된 값)
• 암호화된 값 (C1) : 서버가 XOR 연산한 결과값인 11001000 (이 값은 공격자가 가로챈 값)

▶︎ XOR 연산이란 ? 

XOR 연산 방법

: 각 비트의 값을 비교해 두 값이 같으면 0, 다르면 1이 됩니다.

 

b(01100010) XOR IV(10101010) = 

1. 첫 번째 비트: 0 XOR 1 = 1
2. 두 번째 비트: 1 XOR 0 = 1
3. 세 번째 비트: 1 XOR 1 = 0
4. 네 번째 비트: 0 XOR 0 = 0
5. 다섯 번째 비트: 0 XOR 1 = 1
6. 여섯 번째 비트: 0 XOR 0 = 0
7. 일곱 번째 비트: 1 XOR 1 = 0
8. 여덟 번째 비트: 0 XOR 0 = 0

세션 탈취

• 공격자가 클라이언트의 세션을 탈취하여 IV값과 C1 값을 획득합니다. 

1단계: 첫 번째 시도 (IV = 10101010)

• 공격자는 IV 값을 변경하지 않고 서버로 요청을 보냅니다. 
• 서버는 요청을 복호화 합니다. 
  • 암호화된 값 11001000 XOR IV 10101010 = 01100010 (원래 값 'b')
• 서버는 정상 응답을 줍니다. (하지만 공격자는 아직 원래 값을 모름)

2단계: IV를 한 비트 변경 (IV = 10101011)

• IV의 마지막 비트를 1로 변경하고 서버로 보냅니다.
• 서버의 복호화 : 
  • 암호화된 값 11001000 XOR 새로운 IV 10101011 = 01100011
• 서버는 오류를 반환합니다.
• 공격자는 오류를 보고 IV 값이 올바르지 않다고 추론합니다. 

3단계: IV를 다시 변경 (IV = 10101001)

• IV의 마지막 비트를 다시 0으로 변경하고, 다른 비트를 변경해봅니다.
• 서버는 오류를 반환합니다. 

반복

• 이 과정을 반복하여 서버가 "OK" 메세지를 반환할때까지 계속 IV 값을 변경해나갑니다. 

결론

해당 예시에서는 간편하게 보기 위해, 첫 시도에서 서버가 요청을 정상적으로 처리했기에 데이터를 탈취에 성공했습니다. 하지만 세션에서 탈취한 IV 값과 암호화된 요청을 사용하더라도, 해당 요청이 성공할 수도 있고 실패할 수도 있습니다. 그 이유는 IV 값을 알았다고 해서 항상 데이터가 올바르게 처리되는 것은 아니기 때문입니다. 세션 상태나 데이터 무결성 검증 등 다른 요소에 따라 실패할 수도 있기에, 반복적으로 시도를하여 서버의 응답 패턴을 분석하는 것이 중요합니다. 

---

3. Heartbleed 버그

2014년에 발견된 OpenSSL 1.0.1 버전과 그 하위 버전 라이브러리의 심각한 취약점입니다. 이 버그는 Heartbeat 확장 기능에서 발생하며, 공격자가 서버의 메모리에서 최대 64KB의 데이터를 읽어올 수 있게 만듭니다. 이를 통해 암호화된 세션 정보, 비밀번호, 개인 정보, SSL/TLS 인증서의 비밀 키 등 중요한 데이터를 유출할 수 있습니다.

 

Heartbeat 요청은 클라이언트와 서버간의 연결을 확인하는 일종의 "생존 신고" 라고 볼 수 있습니다. 클라이언트가 서버에게 **나는 이만큼의 데이터를 보냈으니, 그대로 다시 돌려줘** 라고 하여 서버와 연결이 끊어지지 않았는지 확인하는 용도로 사용됩니다.

 

정상적인 클라이언트 요청

 

Heartbleed 버그를 활용하여 공격자는 다음과 같이 공격합니다.

 

구체적으로 : 

 

공격자의 요청

 

1. 공격자가 클라이언트로 서버에 잘못된 Heartbeat 요청을 보냅니다. 이 요청은 정상적인 요청처럼 보이지만, 실제 전송된 데이터는 없고, 요청을 받으면 서버는 64KB의 데이터를 반환하라는 요청을 보냅니다. 
2. 서버는 이 요청을 검증하지 않고 64KB의 메모리를 그대로 클라이언트(공격자)에게 반환합니다. 
3. 공격자는 이 요청을 반복하여, 서버 메모리의 내용을 추출합니다. (메모리는 비밀번호, 세션 쿠키, SSL 키 등이 포함될 수 있습니다)

결론

SSL의 취약점으로 인해 TLS로 전환되면서 웹 보안이 크게 개선되었지만, TLS만으로는 완전한 보안을 보장할 수 없습니다. 공격자들은 여전히 새로운 취약점을 찾아내고, 사회공학적 공격, 네트워크 취약점, 잘못된 설정 등을 통해 시스템을 위협할 수 있습니다. 따라서 안전한 웹 통신을 위해서는 최신 보안 패치 적용, 강력한 인증 및 암호화 알고리즘 사용, 정기적인 보안 모니터링 등 다각적인 보안 관리가 필요합니다.