1 전송 레벨 보안: SSL, TLS
1.1 SSL (Secure Sockets Layer)
1.1.1 SSL 구조
- SSL은 신뢰할 수 있는 종단-대-종단의 안전한 서비스를 제공하기 위해 TCP를 사용하도록 설계되었다.
- SSL은 하나의 프로토콜로 이루어진 것이 아닌, 두 계층의 프로토콜로 이루어져 있다.
- SSL 레코드 프로토콜은 다양한 상위 계층 프로토콜에 기본적인 보안 서비스를 제공한다.
- 웹 클라이언트/서버 상호 교환을 위해 전송 서비스를 제공하는 HTTP는 SSL위에서 작동할 수 있다.
- SSL 연결(Connection)
s 연결이란 적절한 서비스를 제공하는 전송을 말한다.
s SSL에 있어서 연결은 대등-대-대등 관계이다.
s 연결은 일시적이며 모든 연결은 한 개의 세션과 연관된다.
- SSL 세션(Session)
s 한 SSL 세션이란 한 클라이언트와 한 서버 사이의 연관을 말한다.
s 세션을 시작하려면 핸드 셰이크 프로토콜을 이용해야 한다.
s 세션은 다수의 연결이 공유하는 암호적 보안 매개변수를 정의한다.
s 각 연결마다 해야 하는 새 보안 매개변수 협상을 피하기 위해 세션을 사용한다.
1.1.2 SSL 레코드 프로토콜 (SSL Record Protocol)
- SSL 레코드 프로토콜은 전송할 응용 메시지를 다룰 수 있는 크기의 블록으로 잘라내어 단편화한다.
- 옵션으로 데이터를 압축하고, MAC을 적용하여 암호화를 하고, 헤더를 추가하여 결과를 TCP 단편으로 전송한다.
- 수신된 데이터는 복호화하고, 확인하며 압축을 풀고 재조립하여 상위 계층 사용자에게 전달한다.
- SSL 레코드 프로토콜(SSL Record Protocol)은 SSL 연결을 위해 2가지 서비스를 제공한다.
s 기밀성(Confidentiality): 핸드셰이크 프로토콜은 SSL 페이로드를 관용 암호화하는데 쓸 공유 비밀키를 정의한다.
s 메시지 무결성(Message Integrity): 핸드셰이크 프로토콜은 또한 메시지 인증 코드(MAC)를 생성하는데 사용할 공유 비밀키를 정의한다.
- SSL 레코드 프로토콜 동작
1) 단편화 (fragmentation)
s 각 상위 계층 메시지는 214바이트나 이보다 작은 블록으로 단편화한다.
2) 압축 (compression)
s 압축을 할 때는 손실이 없어야만 하며, 내용의 길이가 1024바이트 이상이 되면 안 된다.
3) 메시지 인증 코드(MAC) 계산
s 압축된 데이터의 메시지 인증 코드를 계산하는데, 이 때 공유 비밀키를 사용한다.
4) 암호화
s 압축된 메시지와 MAC을 대칭 암호로 암호화한다.
s 암호화를 할 때 내용의 길이가 1024바이트 이상 늘어나서는 안 된다. 즉, 총 길이가 214+2048바이트를 초과하지 않도록 해야 한다.
5) SSL 레코드 헤더 붙이기
헤더는 다음의 필드로 구성된다.
s 콘텐츠 유형 (Contents Type): 포함된 단편을 처리할 때 사용하는 상위 계층 프로토콜이다.
s 주 버전 (Major Version): 사용 중인 SSL의 주 버전을 나타낸다.
s 부 버전 (Minor Version): 사용 중인 서브버전을 나타낸다.
s 압축된 길이 (Compressed Length): 평문 단편의 바이트 단위 길이로 최댓값은 214+2048이다.
1.1.3 암호명세 변경 프로토콜 (Change Cipher Spec Protocol)
- SSL 레코드 프로토콜을 사용하는 3가지 SSL 지정 프로토콜 중의 하나이며 가장 간단하다.
- 한 바이트로 구성되고 값 1을 갖는 한 개의 메시지로 구성된다. 이 메시지의 유일한 목적은 계류 상태를 현재 상태에 복사하는 것이다.
1.1.4 경고 프로토콜 (Alert Protocol)
- 경고 프로토콜의 각 메시지는 2바이트로 구성된다.
s 첫 번째 바이트는 메시지의 엄밀성을 전달하기 위해 경고 혹은 심각이라는 2가지 값을 갖는다.
레벨이 심각이라면, SSL은 즉시 연결을 단절한다. 동일한 세션 중의 다른 연결은 계속될 수 있지만 이 세션에서 어떤 새로운 연결을 설정하지는 못한다.
s 두 번째 바이트에는 특정 경고를 나타내는 코드가 들어있다.
1.1.5 핸드셰이크 프로토콜 (Handshake Protocol)
- 서버와 클라이언트가 서로를 인증하고 암호와 MAC 알고리즘, SSL 레코드 안에 보낸 데이터를 보호하는데 사용할 암호키를 협상할 수 있다.
- 모든 응용 데이터를 전송하기 이전에 사용된다.
- 클라이언트와 서버가 교환한 연속된 여러 메시지로 구성되며, 각 메시지는 3개의 필드로 구성된다.
s 유형 (Type): 10개의 메시지 중 하나를 나타내며 메시지의 유형을 나타낸다.
s 길이 (Length): 메시지의 길이를 바이트로 나타낸다.
s 내용 (Content): 메시지와 연관된 매개변수이다.
1.1.5.1 핸드 셰이크 프로토콜 동작
단계 1) 보안 기능 설정
s 논리적 연결을 시작하고 이 연결과 연관될 보안 기능을 설정하는데 사용된다.
s 프로토콜 버전, 세션 ID, 암호 조합, 압축 방법, 조기 랜덤 넘버를 포함한다.
s 클라이언트는 client_hello message를 보내는 것으로 교환을 시작한다.
s client_hello message를 보낸 다음 클라이언트는 client_hello message와 동일한 매개변수를 갖는 server_hello message를 기다린다.
단계 2) 서버 인증과 키 교환
s 서버가 필요하다고 생각되면 인증서, 키 교환을 보내고 인증서를 요청한다.
s hello 메시지 단계를 끝내는 것을 말한다.
단계 3) 클라이언트 인증과 키 교환
s 클라이언트는 요청된 인증서를 보낸다.
s 요청이 있었을 경우, 클라이언트는 키 교환을 보낸다.
s 클라이언트는 인증서에 대한 확인을 보낼 수도 있다.
단계 4) 종료
s 암호 조합을 확인하고 핸드 셰이크 프로토콜을 종료한다.
1.2 TLS (Transport Layer Security)
- TLS는 SSL을 인터넷 표준 버전이 되도록 만든 IETF[1] 표준이고, RFC[2] 2246로 제안된 인터넷 표준으로 정의되었다.
- TLS는 인터넷 상에서 통신하고 있는 애플리케이션과 그 사용자들 간에 프라이버시를 지키기 위한 프로토콜이다.
- 서버와 클라이언트가 통신할 때, 어떠한 메시지에 대해서도 제 3자가 엿듣거나 손을 댈 수 없도록 안전하게 지켜준다.
- TLS는 TLS 레코드 프로토콜과 TLS 핸드셰이크 프로토콜의 두 계층으로 구성된다.
- TLS 레코드 프로토콜은 DES와 같은 일부 암호화 방식을 이용하여 접속 보안을 제공하고, 암호화 없이도 사용될 수 있다.
- TLS 핸드셰이크 프로토콜은 데이터가 교환되기 이전에 서버와 클라이언트가 서로 인증하고, 암호화 알고리즘 및 암호 키를 결정하게 해 준다.
- TLS 프로토콜은 SSLv3.0 프로토콜에 기반을 두고 있지만, TLS와 SSL 간에는 상호운용성이 없다.
- TLS 프로토콜은 TLS 구현을 SSLv3.0으로 낮추어 허용하는 메커니즘을 담고 있으며, 최신 버전의 브라우저는 TLS를 지원한다.
1.3 HTTPS
- HTTPS는 웹 브라우저와 웹 서버 간의 안전통신을 구현하기 위한 HTTPS와 SSL의 결합니다.
- HTTPS 기능은 현재 모든 웹 브라우저에 내장되어 있다.
- 검색엔진에는 HTTPS를 지원하지 않는다. 즉, HTTPS 통신을 지원하는 웹 서버에 따라 다르게 사용된다.
- 정상적인 HTTP는 80번 포트를 사용하지만, HTTPS가 지정되면 443번 포트를 사용하여 SSL을 호출한다.
- HTTPS는 HTTP Over TLS라고 하는 RFC 2818 문서로 이루어졌다.
- SSL을 사용하건 TLS를 사용하건 이를 이용하는 HTTP는 기본적으로 차이가 없기 때문에 두 가지 구현을 모두 HTTPS라고 한다.
1.3.1 연결 개시
- HTTPS에서 HTTP 클라이언트 역할을 하는 에이전트는 TLS 클라이언트 역할도 한다.
- 클라이언트는 적절한 포트를 통해 서버에 연결을 시작하고, TLS 핸드셰이크를 시작하기 위해 TLS Client_Hello를 전송한다.
- TLS 핸드셰이크가 마무리되면 클라이언트는 첫 번째 HTTP 요청을 보낸다.
- 모든 HTTPS 데이터는 TLS 응용데이터로서 전송되고, 일반적으로 HTTP는 연결 상태를 유지하면서 다음과 같이 작동한다.
s HTTP 수준에서 HTTP 클라이언트는 하위 계층(TCP 또는 TLS/SSL)으로 연결 요청 메시지를 보내어 HTTP 서버에게 연결 요청을 한다.
s TLS 수준에서 TLS 클라이언트와 TLS 서버 사이의 세션이 설정된다.
s 연결 설정을 위한 TLS 요청은 클라이언트 측의 TCP 개체와 서버 측 TCP 개체 간의 TCP 연결을 설정하여 시작한다.
1.3.2 연결 종료
- HTTP 클라이언트나 서버는 HTTP 레코드에 Connection: close 줄을 집어넣어 연결이 종료되는 걸 나타낼 수 있다.
- HTTPS 연결을 종료하기 위해, TLS가 원격에 있는 상대방의 TLS 개체와의 연결을 종료해야 하는데 그렇게 하려면 하위 TCP 연결을 종료해야 한다.
- TLS 수준에서 연결을 종료하기 위한 적합한 방법은 양쪽에서 close_notify 경보를 보내는 TLS 경보 프로토콜을 사용해야 한다.
- TLS를 종료하기 전에 종료 경보 교환을 시작한다.
- TLS는 종료 경보를 보낸 상대방이 종료 경보를 보낼 때까지 기다리지 않고 연결을 종료해버려서 불완전 종료 상태로 남아 있기도 한다.
- 세션을 재사용하려고 할 때에도 이렇게 수행되기도 하며, 세션 재사용을 하려면 응용 프로그램이 필요한 모든 메시지를 수신했다는 사실을 알고 있을 때에만 그렇게 수행되어야 한다.
- HTTP 클라이언트는 서버 프로그램 오류나 TCP 연결 중단을 일으키는 통신 오류로 인해 발생되는 하위 TCP 연결이 사전 close_notify 경보와 Connection: close 지시자 없이 종료되는 상황에 대처할 수 있어야 한다.
- 만약 갑자기 TCP가 종료되었다면 모종의 공격이 있다는 뜻으로, HTTPS 클라이언트는 이런 상황이 발생하면 보안 경고를 발령해야 한다.
1.4 SSH
- 적은 비용으로 설계한 안전한 네트워크 통신용 프로토콜이다.
- 네트워크 상의 다른 컴퓨터에 로그인하거나 원격 시스템에서 명령을 실행하고 다른 시스템으로 파일을 복사할 수 있도록 해 주는 응용 프로그램 또는 프로토콜을 가리킨다.
- 강력한 인증 방법 및 안전하지 못한 네트워크에서 안전하게 통신을 할 수 있는 기능을 제공한다.
- 기본적으로는 22번 포트를 사용한다.
- SSH는 암호화 기법을 사용하기 때문에 통신이 노출된다 하더라도 이해할 수 없는 암호화된 문자로 보인다.
- SSH는 TCP 상에서 일반적으로 수행되는 3개의 프로토콜로 구성된다.
s 전송 계층 프로토콜 (Transport Layer Protocol)
전방향 기밀[3]을 만족하는 서버인증, 데이터 기밀성과 데이터 무결성을 제공한다. 또한, 전송 계층에서는 옵션으로서 압축을 할 수 있다.
s 사용자 인증 프로토콜 (User Authentication Protocol)
서버에게 사용자를 인증한다.
s 연결 프로토콜 (Connection Protocol)
하나의 기본 SSH 연결을 사용하여 여러 개의 논리적 통신 채널을 다중화한다.
[1] 인터넷 국제 표준화 기구(IETF: Internet Engineering Task Force): 인터넷의 운영, 관리, 개발에 대해 협의하고 프로토콜과 구조적인 사안들을 분석하는 인터넷 표준화 작업기구로 망 설계, 운영자, 업체, 연구자들에 의해 구성되었다.
[2] RFC(Request For Comments): 인터넷 기술과 관련된 공문서 간행물로, 인터넷 연구와 개발 공동체의 작업 문서이다.
[3] 전방향 기밀(Forward Secrecy): 한 세션에서 세션키나 영구 개인키가 손상되더라도 이것은 이전 세션의 기밀성에 영향을 미치지 않는다.
'와사비크래커 IT Tip > 보안' 카테고리의 다른 글
| [보안] IP 보안 프로토콜 (IPSec) (0) | 2020.08.19 |
|---|---|
| [보안] 응용 레벨 보안: PGP, S/MIME (0) | 2020.08.18 |
| [보안] 해쉬 함수와 메시지 인증 (0) | 2020.08.18 |
| [보안] 메시지 무결성 및 키 관리 (0) | 2020.08.14 |
| [보안] 비대칭키(Asymmetric key) 암호화 (0) | 2020.08.14 |
