1. SSL 프로토콜의 개요
SSL(Secure Socket Layer)는 넷스케이프에서 개발한 보안 프로토콜로 전송 프로토콜(ex, TCP/IP)상에서 송수신자간에 통신의 비밀성과 데이터 무결성을 제공하는 것을 목적으로 한다.
현재 인터넷은 SSL2.0, SSL3.0, TLS1.0이 함께 사용되고 있으며 넷스케이프와 익스플로러에서 이를 지원하고 있다.
웹서버에서 SSL을 가장 쉬운 보안 프로토콜로 채택하고 있는 이유는 사용자가 특별한 프로그램을 다운로드 받지 않아도 넷스케이프와 익스플로러가 자동으로 보안 채널을 연결해주기 때문이다. 즉, 웹서버 설치시 SSL과 인증서를 포팅하면 된다.
미국에서 생산된 웹서버나 인증서는 1999년 중반까지 암호 수출 정책의 영향을 받았기 때문에 암호 프로토콜 이용시 키 길이가 대칭키 40비트, 비대칭키 512비트로 제한됐었다. 현재는 이같은 제한이 완화돼 넷스케이프 4.72, 익스플로러 5.01 이상은
대칭키 128비트, 비대칭키 1024비트를 사용할 수 있다.
하지만 새로운 정책이 적용된 인증서를 이용하지 않고 있는 웹사이트는 여전히 많은 편이다.
2. SSL 프로토콜의 구조
SSL은 크게 핸드세이크 프로토콜과 레코드 프로토콜로 되어있다. 핸드세이크 프로토콜은 다시 체인지 사이퍼 스펙 프로토콜(Change cipher spec protocol), 얼러트 프로토콜(Alert Protocol), 핸드세이크 프로토콜로 나뉘어 진다.
SSL은 클라이언트와 서버간에 핸드세이크 프로토콜을 수행해 암호화된 하나의 세션을 성립하게 된다.
이 세션 동안 보안 서비스를 위한 세션키, 암호 알고리즘, 인증서 등과 같은 변수 등을 서로 공유해야 하며, 이 정보를 이용해 레코드 프로토콜에서 실질적인 보안 서비스를 제공한다. 여기에 이용되는 세션 정보는 다음과 같다.
: 세션 상태가 active상태인지 resemble상태인지를 식별하기 위해 임의로 선택된 일련의 바이트.
: 서버와 클라이언트 X509.v3 인증서
: 데이터 압축을 위해 사용한 알고리즘
: 암호 알고리즘( DES etc.)과 MAC 알고리즘( MD5 or SHA), hash_size등의 알고리즘 관련 정보
: 클라이언트와 서버 사이에 공유하는 48바이트의 비밀 정보
: 세션 재 연결 시 세션 정보를 재 사용할 지 여부 표기
세션 정보 중 한 세션 동안에만 이용되는 정보는 다음과 같다.
: 서버와 클라이언트의 연결을 위해 선택된 일련의 바이트
: 서버가 데이터에 MAC 연산을 적용할 때 사용한 비밀
: 클라이언트가 데이터에 MAC연산을 적용할 때 사용한 비밀
: 서버가 암호화하고 클라이언트가 복호화할 때 사용하기 위한 암호키
: 클라이언트가 암호화하고 서버가 복호화할 때 사용하기 위한 암호키
: CBC모드에서 블럭을 암호화할 때 각 키에 초기화 벡터(IV)가 포함된다. 이 필드는 SSL 핸드쉐이크 프로토콜에 의해 초기화된다. 각 레코드의 마지막 암호문은 이후의 레코드와 함께 사용하기 위해 보존.
: 송수신되는 각 메시지에 대한 순서 번호 @
SSL(Secure Sockets Layer) 프로토콜은 넷스케이프에서 개발됐으며 현재 웹에서 클라이언트와 서버간의 암호화 인증통신의 표준이 된 기술이다.
IRTF(The new Internet Engineering Task Force)는 TLS(Transport Layer Security)라고도 하는데 이것 또한 SSL에 기반을 두고 있다. TLS는 얼마전에 공개된 바 있으며, 넷스케이프에서도 지원된다.
본 내용은 넷스케이프 서버 관리자에게 SSL에 대한 정보를 제공하기 위해 제작됐기 때문에 SSL 환경에서 작업하는 모든 개발자들에게 유용한 정보가 될 것이다.
그러면 독자 여러분들이 PKI(공개키 기반구조)의 기본적인 개념에 대해서 충분히 숙지하고 있다고 가정하고 설명을 하겠다. PKI에 대해 더욱 자세하게 알고 싶다면 이곳을 참조하길 바란다.
SSL 프로토콜
TCP/IP(Transmission Control Protocol/Internet Protocol)는 인터넷 정보 전송의 기반이 되는 프로토콜이다. HTTP(HyperText Transport Protocol)나 LDAP(Lightweight Directory Access Protocol), IMAP(Internet Messaging Access Protocol)같은 경우에는 웹페이지를 보여주거나 이메일 서버를 가동시킬 때 필수적으로 TCP/IP를 사용하므로 이러한 프로토콜들은 모두 TCP/IP 상에서 구동된다고 할 수 있다.
이 그림을 보면 SSL은 TCP/IP 상에서, 그리고 HTTP/LDAP/IMAP같은 상위 레벨에 위치한 애플리케이션 프로토콜에서 구동된다고 볼 수 있다. 즉 SSL은 TCP/IP를 상위 레벨에 위치한 프로토콜 대신 사용하며 SSL 서버가 SSL 클라이언트에게 자신을 증명하거나 SSL 클라이언트가 SSL 웹서버에게 자신을 증명할 수 있도록 해준다. 그러면 양측에서 암호화 통신을 수립할 수 있게된다.
SSL 프로토콜에는 2개의 서브프로토콜이 있다. SSL 레코드 프로토콜과 SSL 핸드세이크 프로토콜이 그것인데, SSL 레코드 프로토콜은 데이터를 전송할 때 이용되는 포맷이며 SSL 핸드세이크 프로토콜은 SSL 서버와 SSL 클라이언트가 최초로 SSL 연결을 수립했을 때 메시지를 교환하는것과 관련된 프로토콜이다. 메시지 교환에 관련된 사항은 다음과 같다.
- 서버를 클라이언트에게 승인한다.
- 클라이언트와 서버가 암호화 알고리즘 또는 암호문을 사용하도록 해준다.
- 선택에 따라 클라이언트를 서버에 승인한다.
- 공유암호 생성과정에 공개키 암호화 기술을 이용한다.
- 암호화된 SSL 연결이 구축된다.
SSL 프로토콜은 서버 및 클라이언트 인증, 인증서 전송, 세션키 수립에 필요한 다양한 암호화 알고리즘과 암호문을 지원한다. 서버 및 클라이언트가 지원하는 암호문의 종류는 현재 이용하는 SSL의 버전과 사용자가 선택하는 암호화 수준, SSL을 구현할 수 있는 소프트웨어의 수출금지법 적용여부 등에 따라 각각 달라지게 된다.
암호화 알고리즘 목록 :
KEA나 RSA 키 익스체인지와 같은 키 교환 알고리즘에 따라 클라이언트와 서버가 SSL 세션 수립에 사용할 대칭키를 선택하는 방법이 결정됩니다. 가장 일반적으로 이용되는 SSL 암호문은 RSA 키 익스체인지 방식을 따른다.
SSL 2.0과 SSL 3.0 프로토콜은 공통으로 지원하는 암호문을 갖고 있으며 관리자가 클라이언트 및 서버에서 지원가능한 암호문의 종류를 자유롭게 설정할 수 있습니다. 특정 서버와 클라이언트가 SSL 핸드세이크시 정보를 교환하게 되면 양쪽에서는 공통으로 갖고 있는 암호문 중 가장 강력한 수준의 암호문을 SSL 세션에 사용하게 됩니다.
SSL을 사용하는 업체에서는 보호할 데이터의 중요성과 암호화 스피드, 수출금지법의 적용여부에 따라 어떤 수준의 암호문을 사용할지를 결정하게 됩니다.
물론 상대적으로 취약한 보안성을 가진 40/56비트의 SSL 암호문을 사용하지 않으려는 업체들도 있었지만 미국 정부는 40비트 이상의 암호화를 제공하는 상품에 대한 수출을 규제했기 때문에 미국 이외에서도 강력한 암호화 수준을 이용할 수 있는 글로벌 서버 ID를 제외하면 미국 외 지역에서 128비트의 강력한 암호문을 이용할 수 없었다. 미국의 수출금지법에 대해 자세히 알고 싶으면 Export Restrictions on International Sales를 참조해라.
SSL을 이용하는 업체에서 많은 고객을 확보하려면 웹서버에서 이용하고 있는 SSL의 암호화 범위를 확장시킬 수 있어야 한다. 국내 클라이언트나 서버가 국내의 다른 서버나 클라이언트와 거래하고 있다면, 서버나 클라이트는 공통으로 최대한 높은 수준의 암호문을 사용할 것이다. 국내 클라이언트나 서버가 외국의 서버나 클라이언트와 거래하고 있다면 미국 수출금지법하에서 허용되는 암호문을 사용하게 될 것이다(현재는 수출금지법이 폐지됐기 때문에 해당사항 없음).
하지만 40비트 암호문은 상대적으로 쉽게 해독될 수 있으므로 제 3자의 정보 도용을 방지하고자 한다면 강력한 암호화 기능을 이용해야 한다.
※ 본 내용은 developer.netscape.com에서 참조했다. @