Chapter.2 Introduction

Cryptographic Techniques

SSL 이해하기 위해서는 암호화 알고리즘, 메시지 다이제스트(one-way or hash function), 전자서명에 대한 이해가 필요하다. technique들은 privacy, integrity, authentication 있어서의 basis 제공한다.

Cryptographic Algroithm

Alice 돈을 옮기기 위하여 자신의 은행에 메시지를 보낸다고 가정하자. 메시지에는 Alice 계좌번호, 송금액 등과 같은 정보가 포함되기 때문에 Alice 메시지가 private하기를 원한다. 이에 대한 해결책은 암호화 알고리즘을 사용하는 것이며, 암호화를 사용함으로써 Alice 메시지를 암호화된 형태로 전송하여 다른 사람들로 하여금 읽을 없도록 만든다.

메시지는 secret key 사용하여야만 해석되어질 있으며, key 없으면 메시지는 무용지물이 된다. 좋은 암호화 알고리즘은 공격자(intruder) 원래의 메시지로 decoding하는 것을 어렵게 만듦으로써 공격자의 수고를 가치 없게 만든다.

암호화 알고리즘에는 두가지 범주가 있다. : Conventional, Public key.

Conventional Cryptography

  • symmetric cryptography라고도 하며, 메시지의 송신자, 수신자가 동일한 key 공유하게 되며, key 메시지를 암호화하고 복호화하는데 사용되는 secret piece of information이다. key 안전하게 보관됨으로써 전송자와 수신자 이외에는 메시지를 읽지 못하게 된다. 만약 Alice 은행이 secret key 알고 있다면 그들은 서로에게 private message 전송할 있다. 그러나 통신 이전에 key private하게 공유하는 것이 문제가 있다.

Public Key Cryptography

  • asymmetric cryptography라고도 하며, 두개의 key 사용하는 알고리즘을 정의함으로써 key exchange 문제를 해결하며, 두개의 key 어느 것도 메시지를 암호화하는데 사용될 있다. 만약 하나의 키가 메시지를 암호화하는데 사용되었다면 다른 하나의 key 그것을 복호화하는데 사용되어져야 한다. 공개키 암호화는 단순히 하나의 (공개키) 공개하고 다른 하나의 (개인키) 보관함으로써 메시지를 안전하게 전달할 있게 해준다.

  • 누구나 공개키를 사용하여 메시지를 암호화할 있지만 해당되는 개인키를 가진 사람만이 메시지를 읽을 있다. 이러한 방식으로 Alice 은행의 공개키로 메시지를 암호화함으로써 키쌍의 주인인 은행으로 private message 보낼 있게 되며, 단지 은행만이 메시지를 복호화할 있다.

메시지 다이제스트

비록 Alice 자신의 메시지를 암호화함으로써 안전하게 만들 수는 있지만, 누군가가 돈을 가로채기 위하여 Alice original message 변조하거나 다른 message 바꿔치기 있다는 문제가 여전히 존재한다. Alice 메시지에 대한 무결성(integrity) 보장하는 하나의 방법은 Alice 메시지에 대한 간결한 요약(summary) 생성해서 메시지와 함께 은행으로 보내는 것이다. 메시지를 받게 되면 은행은 메시지의 summary 다시 생성해서 Alice 보낸 것과 비교하게 되며, 두개가 일치하면 메시지는 손상되지 않은 것이다.

이러한 summary 메시지 다이제스트, one-way function, 혹은 hash function이라고 부른다. Message digests are used to create short, fixed-length representations of longer, variable-length messages. 다이제스트 알고리즘은 서로 다른 메시지에 대하여 각각 유일한 다이제스트를 생성하도록 디자인되어진다. 또한 다이제스트로부터 원래의 메시지를 얻어내는 것이 매우 어렵게 되어 있으며, 동일한 다이제스트를 가지는 서로 다른 두개의 메시지를 찾는 것이 불가능하다. 따라서 어떤 메시지를 동일한 다이제스트를 가지는 다른 메시지로 바꿔치기할 가능성을 막아주게 된다.

Alice 직면하게 되는 다른 문제는 다이제스트를 은행으로 안전하게 보내는 방법이며, 문제가 해결되면 해당 메시지에 대한 무결성이 보장된다. 이를 위한 한가지 방법은 다이제스트를 전자 서명에 포함하는 것이다.

전자 서명(Digital Signatures)

Alice 은행으로 메시지를 전송하였을 은행은 공격자(intruder) Alice 계좌로부터 돈을 인출하는 것을 막기 위해 메시지가 정말로 Alice 보낸 것인가를 확인할 필요가 있다. 역할을 하는 것이 Alice 생성하여 메시지에 포함한 전자 서명이다.

전자 서명(Digital signatures) 메시지의 다이제스트와 다른 정보들(sequence number 같은) 전송자(sender) 개인키로 암호화함으로써 생성된다. 비록 누구나 전송자의 공개키를 가지고 서명을 복호화할 수는 있지만 단지 서명자만이 개인키를 알고 있을 뿐이며, 이것은 서명자만이 서명을 생성할 있음을 의미한다. 서명에 다이제스트를 포함한다는 것은 서명이 단지 메시지에 대해서만 유효함을 의미한다. 이것은 또한 누구도 다이제스트를 변경하지 못하며 서명을 없기 때문에 메시지의 무결성을 보장해준다.

Intruder 의한 가로채기(interception) 서명의 재사용을 막기 위하여 서명은 유일한 sequence number 포함하고 있으며, 이것은 은행으로 하여금 Alice 자신이 메시지를 보내지 않았다고 하는 부정하게(fraudulent) 클레임을 거는 것을 막아주게 된다. 이유는 단지 Alice만이 메시지에 서명할 있기 때문이다. 이를 부인봉쇄(non-repudiation)이라고 한다.

인증서(Certificates)

비록 Alice private message 은행으로 보내고, 메시지에 서명하고 또한 메시지의 무결성을 보장받을 있지만 여전히 Alice 자신이 정말로 은행과 통신(communicate)하고 있는가를 확인할 필요가 있다. 이것은 자신이 사용하는 공개키가 은행의 개인키와 대응되는가를 확인할 필요가 있음을 의미한다. 또한 은행 역시 메시지의 서명이 정말로 Alice 서명에 대응되는가를 확인할 필요가 있다.

만약 party 서로의 identity validate해주고 공개키를 confirm해주며, 또한 믿을 있는 agency 의해 서명된 증명서(certificate) 가진다면 그들은 자신이 생각하고 있는 올바른 상대방과 통신하고 있음을 확신할 있을 것이다. 이러한 믿을 있는 agency Certificate Authority라고 부르며, 증명서(certificate) 인증(authentication) 사용된다.

Certificate Contents

증명서는 하나의 공개키와 실재의 subject 보여지는 identity(individual, server 등등) 연관시킨다. subject 대한 정보는 identifying information(the distinguished name) 공개키를 포함한다. 또한 증명서는 증명서를 발급한 CA 대한 identification 서명, 그리고 증명서의 유효기간을 포함한다. 증명서에는 serial number 같이 CA 관리적 목적으로 사용하기 위한 administrative information 같은 부가적인 정보를 가질 수도 있다.

Subject:

Distinguished Name, Public Key

Issuer:

Distinguished Name, Signature

Period of Validity:

Not Before Date, Not After Date

Administrative Information:

Version, Serial Number

Extended Information:

Basic Contraints, Netscape Flags, etc.

Table 1: Certificate Information

Distinguished name 특정한 context 내에서 identity 제공하기 위해 사용된다. 예를 들어, 개인(individual) 개인 증명서(personal certificate) 뿐만 아니라 하나의 employee로서의 증명서을 가진다. Distinguished name X.509 표준[X509] 정의되어 있으며, 여기에는 field, field name, abbreviation(약어) 정의되어 있다.

A distinguished name is used to provide an identity in a specific context ? for instance, an individual might have a personal certificate as well as one for their identity as an employee. Distinguished names are defined by the X.509 standard [X509], which defines the fields, field names, and abbreviations used to refer to the fields (see Table 2).

DN Field:

Abbrev.:

Description:

Example:

Common Name

CN

Name being certified

CN=Joe Average

Organization or

Company

O

Name is associated with this organization

O=Snake Oil, Ltd.

Organizational Unit

OU

Name is associated with this organization unit, such as a department

OU=Research Institute

City/Locality

L

Name is located in this City

L=Snake City

State/Province

ST

Name is located in this State/Province

ST=Desert

Country

C

Name is located in this Country (ISO code)

C=XZ

Table 2: Distinguished Name Information

CA 어떤 DN name 필수적(required)이냐, 부가적(optional)이냐를 명시하는 정책(policy) 정의할 있으며, 또한 필드의 내용(field content) 대한 요구사항(requirement) 포함할 있다. 예를 들면, Netscape 브라우져는 어떤 서버에 대한 증명서의 Common Name 서버의 도메인 네임에 대한 wildcard pattern ( *.snakeoil.com 같은…) 부합(match)되는 이름을 가질 것을 요구한다.

증명서의 binary format ASN.1 notation [ X208] [PKCS] 사용하여 정의한다. notation content information binary form으로 변환하는 방법을 정의하는 encoding rule들을 어떻게 specify하는가를 정의한다. 증명서의 binary encoding Distinguished Encoding Rules(DER) 사용하여 정의하며, DER 일반적인 Basic Encoding Rules(BER) 기반을 두고 있다. Binary 다루지 못하는(cannot handle) transmission 위하여 binary form Base64 encoding [MIME] 사용하여 ASCII form으로 변환될 수도 있다. 이렇게 encoding 버전을 PEM(“Privacy Enhanced Mail”에서 얻어진 이름) encoded라고 부르며, [Table3]에서와 같이 begin delimiter line end delimiter line 사이에 놓여진다.

-----BEGIN CERTIFICATE-----

MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx

FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG

A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv

cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz

bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL

MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h

a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl

cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN

AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB

gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b

vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa

lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV

HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB

gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt

2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7

dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==

-----END CERTIFICATE-----

Table 3: Example of a PEM-encoded certificate (snakeoil.crt)

인증기관(Certificate Authorities)

CA 증명서를 발급하기 전에 먼저 증명서에 있는 정보를 확인(verify)함으로써 키쌍의 개인키의 identity 확인(assure)한다. 예를 들어 만약 Alice 개인 증명서(personal certificate) 요청하는 경우 CA 반드시 먼저 Alice 정말로 증명서를 요청한 사람인가를 확인하여야 한다.

Certificate Chains

CA 다른 CA 대한 증명서을 발급(issue) 있다. 증명서를 examining Alice Alice 신뢰할 있는 CA 도달할 때까지 parent CA 대한 issuer 증명서를 examine해야 필요가 있을 있다. Alice chain안의 “bad” certificate 대한 위험을 줄이기 위하여 제한된 chain(limited chain of issuers) 가진 증명서만을 신뢰할 것을 결정할 수도 있다.

Creating a Root-Level CA

위에서 언급된 바와 같이, certificate들은 top-level CA 도달할 때까지 certificate subject identity 대한 유효성(validity) certificate issuer 보증해야 한다. 이것은 하나의 문제를 발생시키는데, 그것은 issuer 가지지 않는 top-level authority certificate 누가 보증하는가의 문제이다. 이런 특정한 경우, top-level authority certificate “self-signed”되어지며, 증명서의 issuer subject 동일하게 된다. 결과로서 self-signed certificate 신뢰에 대한 문제가 생긴다. Root authority 의한 공개키의 wide publication 공개키의 신뢰에 대한 위험을 줄여줄 있는데, 누군가가 자신이 authority 되겠다고 하면서 키를 공표함으로써 문제를 해결할 있다. 보통 브라우져들은 well-known CA들을 신뢰할 있도록 미리 설정되어있다(preconfigured).

Thawte이나 VeriSign 같은 몇몇 회사들이 자신을 Certificate Authority로서 입지를 굳혀왔으며, 이들은 다음과 같은 서비스를 제공한다:

  • 증명서 요청에 대한 확인(Verifying certificate requests)

  • 증명서 요청의 처리(Processing certificate requests)

  • 증명서의 발급과 관리(Issuing and managing certificates)

자기 자신만의 CA(one’s own CA) 생성하는 것도 가능한데, 비록 인터넷 환경에서는 위험하긴 하지만 어떤 조직 내에서 개인이나 서버들을 확인(verify)하기 위한 목적의 인트라넷 환경에서는 매우 유용할 있다.

Certificate Management

CA 설립(establishing)하는 것은 믿을 있는 관리적(administrative), 기술적(technical), 관리(management) framework 요구하는 일이다. CA 증명서를 발급할 뿐만 아니라 증명서를 관리해야 한다. , 증명서가 어느 기간 동안 유효한가를 결정하고, 증명서를 갱신하며, 발급은 되었지만 이상 유효하지 않은 증명서들의 리스트(Certificate Revocation Lists - CRL) 관리해야 한다. 만약 Alice에게 어떤 회사의 직원으로서의 증명서를 발급하였다면 Alice 회사를 떠날 증명서는 취소되어야 필요가 있다. 그러나 증명서는 돌아다니는 것이기 때문에 증명서 자체만으로는 그것이 취소되었다는 것을 알려줄 없다. 따라서 증명서의 유효성(validity) 확인하고자 CRL 체크하기 위해서 증명서를 발급한 CA 문의(contact) 필요가 있다(보통 이것은 자동으로 되는 프로세스가 아니다-- this is not usually an automated part of the process).

Note:

브라우져에 디폴트로 설정되어져 있지 않은 CA 사용하는 경우, 브라우져로 하여금 CA 서명한 server certificate 확인(validate) 있도록 하기 위해 CA certificate 브라우져에 load해야 하는데, 이것은 브라우져가 일단 한번 CA certificate load하면 CA 서명한 모든 certificate 받아들이게 되기 때문에 위험할 있다.

 

Secure Sockets Layer (SSL)

Secure Sockets Layer protocol Reliable connection-oriented network layer protocol (e.g. TCP/IP) Application protocol layer (e.g. HTTP) 사이에 위치하는 Protocol Layer이다. SSL 상호 인증, 무결성을 위한 전자 서명의 사용, privacy 위한 암호화 등을 이용하여 클라이언트와 서버간의 안전한 통신을 제공한다.

프로토콜은 암호화, 다이제스트, 서명을 위한 특정 알고리즘의 선택을 지원하도록 디자인되어졌다. 이것은 특정 서버의 알고리즘 선택이 법적인 문제나 수출법과 같은 문제에 기반하여 이루어질 있도록 해주며, 또한 프로토콜로 하여금 새로운 알고리즘의 채택을 가능하게 해준다. 알고리즘의 선택은 프로토콜 세션이 시작될 클라이언트와 서버 간에 협상(negotiation)된다.

Version:

Source:

Description:

Browser Support:

SSL v2.0

Vendor Standard

(from Netscape Corp.)

[SSL2]

First SSL protocol for which implementations exists

- NS Navigator 1.x/2.x

- MS IE 3.x

- Lynx/2.8+SSLeay

SSL v3.0

Expired Internet Draft

(from Netscape Corp.)

[SSL3]

Revisions to prvent specific security attacks, add non-RSA ciphers, and support for certificate chains

- NS Navigator 2.x/3.x/4.x

- MS IE 3.x/4.x

- Lynx/2.8+SSLeay

TLS v1.0

Proposed Internet Standard

(from IETF)

[TLS1]

Revision of SSL 3.0 to update the MAC layer to HMAC, add block padding for block ciphers, message order standardization and more alert messages.

- Lynx/2.8+SSLeay

Table 4: Versions of the SSL protocol

[Table 4] 보여지는 바와 같이 몇가지 버전의 SSL 프로토콜이 있다. 위에 기술된 바처럼, SSL 3.0 장점 하나는 certificate chain loading 지원한다는 것이며, 이것은 서버가 브라우져에게 issuer certificate 함께 서버의 certificate 넘겨주는 것을 가능하게 해준다. 또한 Chain loading 기능은 해당 서버 certificate 서명한 issuer CA certificate 브라우져에 설치되어 있지 않은 경우에도 server certificate certificate chain 포함되어 있기 때문에 브라우져가 server certificate 확인(validate) 있도록 해준다. Transport Layer Security [TLS] protocol standard SSL 3.0 기반으로 하였으며, 현재 Internet Engineering Task Force (IETF) 의해 개발되고 있다.

Session Establishment

SSL 세션은 [Figure 1]에서와 같이 클라이언트와 서버 간의 handshake sequence 따라 이루어진다. sequence 서버가 server certificate 제공하느냐, 혹은 client certificate 요구하는가에 따라 달라질 있다. Cipher information 관리를 위해 부가적인 handshake step 요구되는 경우도 존재하지만 여기서는 하나의 일반적인 시나리오를 정리한다: 가능한 모든 경우에 대한 설명은 SSL specification 참조하라

Note

일단 SSL 세션이 이루어지면 이것은 재사용되어질 있으며, 이로 인하여 세션을 시작하기 위해 필요한 많은 단계들을 반복함으로써 발생하는 performance penalty 피할 있다. Reusing 기능을 위하여 서버는 SSL 세션마다 유일한 session identifier 할당하며, identifier 서버에 저장되어서 이후에 클라이언트가 다시 연결할 이를 사용함으로써 handshake 줄일 있다(session identifier 서버의 캐쉬에서 지워지기 이전까지 사용할 있다).
 

Figure 1: Simplified SSL Handshake Sequence
 

Handshake sequence 요소는 다음과 같다.

  1. 데이터 전송 시에 사용할 Cipher Suite 협상(negotiation)한다.( Negotiate the Cipher Suite to be used during data transfer)

  2. 클라이언트와 서버 간의 세션키를 공유한다.( Establish and share a session key between client and server)

  3. 부가적으로(Optionally) 클라이언트에게 서버를 인증한다.(authenticate the server to the client)

  4. 부가적으로(Optionally) 서버에게 클라이언트를 인증한다.(authenticate the client to the server)

첫번째 단계인 Cipher Suite Negotiation에서 클라이언트와 서버는 양측 모두가 지원할 있는 Cipher Suite 선택한다. SSL 3.0 프로토콜 규격은 31개의 Cipher Suite 정의되어 있다. 하나의 Cipher Suite 다음의 요소들로 정의된다:

  • Key Exchange Method

  • Cipher for Data Transfer

  • Message Digest for creating the Message Authentication Code (MAC)

Key Exchange Method

Key exchange method 어플리케이션 데이터의 전송에 사용할 공유 비밀키를 어떻게 클라이언트와 서버간에 동의(agree) 것인가를 정의한다. SSL 2.0 RSA 교환만을 지원하지만 SSL 3.0 가지 교환 알고리즘(RSA key exchange, Diffie-Hellman key exchange) 중에 선택할 있도록 지원한다. RSA 교환은 certificate 사용되는 경우에 선택되며, Diffie-Hellman 교환은 certificate 없고 클라이언트와 서버 간의 통신이 이전에 한번도 없는 경우에 선택된다.

Key exchange method 선택에 있어서 하나의 변수는 전자 서명을 사용할 것인가 사용하지 않을 것인가, 그리고 사용한다면 어떤 종류의 서명을 사용할 것인가이다. 개인키를 이용한 서명을 사용함으로써 공유키를 생성하는데 사용되는 정보를 교환할 man-in-the-middle-attack 막을 있다 [AC96, p516].

Cipher for Data Transfer

SSL 세션 내의 메시지를 암호화하기 위해서 위에서 기술된 conventional cryptography algorithm(대칭형 암호화) 사용한다. 암호화를 하지 않는 경우를 포함해서 9가지의 선택이 가능하다:

No encryption

Stream Ciphers

  • RC4 with 40-bit keys

  • RC4 with 128-bit keys

CBC Block Ciphers

  • RC2 with 40 bit key

  • DES with 40 bit key

  • DES with 54 bit key

  • Triple-DES with 168 bit key

  • Idea (128 bit key)

  • Fortezza (96 bit key)

“CBC” Cipher Block Chaining 의미하며, 모드에서는 바로 이전에 암호화된 암호문의 일부가 현재 block 암호화에 사용되어진다. “DES” Data Encryption Standard 의미하며, 여러가지의 variant(DES40, 3DES_EDE) 있다. "Idea" 암호학적으로 가장 강력한 알고리즘이며, "RC2" RSA DSI에서 개발한 독점적인 알고리즘이다.

Digest Function

Digest Function 선택은 record unit으로부터 어떻게 다이제스트가 생성되어지는가를 결정하며, SSL 다음을 지원한다:

  • No digest (Null choice)

  • MD5, a 128-bit hash

  • Secure Hash Algorithm (SHA-1), a 160-bit hash

메시지 다이제스트는 Message Authentication Code (MAC) 생성하는데 사용된다. MAC 메시지와 함께 암호화됨으로써 메시지의 무결성을 제공하며 또한 replay attack 막아준다.

Handshake Sequence Protocol

Handshake sequence 가지의 프로토콜을 사용한다:

  • 클라이언트와 서버 간 SSL 세션 수립을 위한  SSL Handshake 프로토콜.

  • 세션에 사용될 암호 수트(Cipher Suite)를 결정하기 위한 SSL Change Cipher Spec 프로토콜.

  • 클라이언트와 서버 간 에러 메시지를 전달하기 위한 SSL Alert 프로토콜.

Figure 2: SSL Protocol Stack

어플리케이션 프로토콜 데이터 및 이 프로토콜 자체는 Figure 2와 같이, SSL Record 프로토콜에 의해 싸여지며(encapsulated), 아래 계층의 프로토콜은 위의 싸여진 데이터가 무엇인지 상관하지 않고 일반적인 데이터로서 취급하여 전달하게 된다. 프로토콜 계층에서 상위의 싸여진 프로토콜 역시 아래 계층의 프로토콜이 무엇인지 상관하지 않는다.

Record 프로토콜에 의한 SSL 제어 프로토콜의 캡슐화는 만약 활성화된 세션이 재협상(renegotiated)되는 경우 제어 프로토콜이 안전하게 전달될 것임을 의미한다. 만약 이전에 세션이 존재하지 않았다면 널(NULL) 암호 수트가 사용되며, 이는 세션이 수립되기 전까지는 Integrity digest를 가지지 않는 암호화 및 메시지가 존재하지 않는다는 것을 의미한다.
 

Data Transfer


Figure 3: SSL Record Protocol


SSL Record 프로토콜 어플리케이션 데이터와 SSL 관리 데이터 작은 unit 쪼개거나, 복수의 상위 계층 프로토콜 데이터 메시지들을 하나의 unit 결합하여 클라이언트와 서버 간에 전송한다. 이 단계에서 데이터를 압축하고, 전자 서명을 붙이고, Unit들을 암호화한 후 하위의 프로토콜에 실어서 전송하게 된다. (Note: 현재 모든 주요 SSL 구현은 압축을 지원하지 않고 있다). 
 

Securing HTTP Communication

SSL 보통 브라우져와 서버 간의 HTTP 통신을 안전하게 만드는데 사용되며, 경우 non-secure HTTP 사용하지 않는 것이 아니라, SSL 위에서 일반적인 plain HTTP 구현한다(HTTPS라고 한다). 한가지 중요한 차이는 HTTPS 이용할 http 다른 서버 포트(디폴트 443) 사용하는 것이 아니라 https라는 URL scheme 사용한다는 것이며, 이것이 mod_ssl Apche 웹서버에 제공하는 주요한 기능이다.

References

[AC96] Bruce Schneier, Applied Cryptography, 2nd Edition, Wiley, 1996. See

http://www.counterpane.com/ for various other materials by Bruce Schneier.

[X208] ITU-T Recommendation X.208, Specification of Abstract Syntax Notation One (ASN.1), 1988.

See for instance ftp://ftp.neda.com/pub/itu/x.series/x208.ps.

[X509] ITU-T Recommendation X.509, The Directory ? Authentication Framework, 1988.

See for instance ftp://ftp.bull.com/pub/OSIdirectory/ITUnov96/X.509/97x509final.doc.

[PKCS] Kaliski, Burton S., Jr., An Overview of the PKCS Standards, An RSA Laboratories Technical Note, revised November 1, 1993. See http://www.rsa.com/rsalabs/pubs/PKCS/.

[MIME] N. Freed, N. Borenstein, ultipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, RFC2045. See for instance ftp://ftp.isi.edu/in-notes/rfc2045.txt.

[SSL2] Kipp E.B. Hickman, The SSL Protocol, 1995.

See http://www.netscape.com/eng/security/SSL_2.html.

[SSL3] Alan O. Freier, Philip Karlton, Paul C. Kocher, The SSL Protocol Version 3.0, 1996. See

http://www.netscape.com/eng/ssl3/draft302.txt.

[TLS1] Tim Dierks, Christopher Allen, The TLS Protocol Version 1.0, 1997. See

ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-protocol-06.txt.

Posted by Golmong
:


90년대 후반 우리나라에도 인터넷이 보편화되고 다양한 IT 기술들이 등장하고 사용되지만 당시에는 많은 IT 기술 문서들이 대부분 영문들이고 한글로 된 기술문서들이 부족했던 시절이었는데, 이에 따라서 KLDP와 같은 다양한 기술문서 한글화 작업 프로젝트들이 많이 시작되었으며 젊은 엔지니어들은 오픈소스 프로젝트와 더불어 이러한 한글화 프로젝트에 contribution 하는 의무감이 유행하던 적이 있었다.
당시 나도 공부도 할겸 RFC나 암호 관련 문서들을 꽤 많이 번역하고 일부는 KLDP 등에 쾌척하면서 스스로 뿌듯함을 느끼던 적도 많았는데, 점점 나이를 먹고 조직에서 직급도 올라가면서 소위 관리 업무들이 많아지니 점점 예전의 그러한 열정을 잃어가고 그 때는 그렇게 재미있게 느껴지던 공부들이 이젠 관심조차 가지 않는 나를 보며 스스로 많이 느슨하게 살고 있다는 느낌을 받을 때가 많아진다.
지금도 예전의 그 열정을 유지할 수 있다면 삶이 조금은 더 나아질 수 있지 않을까....

오랜만에 PC 정리하다가 찾은 그 시절에 아르바이트 겸 공부 겸 해서 번역했었던 Mod_SSL 기술 문서들...
지금 올라와 있는 문서들과 비교하면 introduction 정도 변경이 있는 것 같긴 하지만 핵심 내용은 거의 변경이 없는 듯 하니 혹시나 도움이 되실 분들이 있을까 하여 한번 정리해 올려본다.
지금 보면 짧은 지식에 번역하면서 해석이 이상한 것도 많고 대충 대충 한 것도 많지만 다 과거의 기록이라는 핑계로, 귀찮기도 하니 그냥 올리니 혹시 이상한 부분이 있으면 댓글로 남겨주시면 감사하겠다.

mod_ssl의 최종 문서 주소는 아래와 같다.

http://www.modssl.org/docs/2.8/index.html 

암호 기술 분야의 좋은 점 중 하나는 15년이 지나도 사용되는 기술이 변하지 않는다는 점이 아닐까 싶다. 기껏해야 보안성 강화를 위해 RSA의 키 길이를 1024에서 2048 bit 로 올리는 정도의 변화가 있었을 뿐...
아마도 단언하건데 앞으로 15년 후에도 지금과 동일한 스키마에 동일한 알고리즘이 그대로 사용되고 있을 것이라고 강하게 추정하는 바이다.

Chapter1 OverView

module Eric A. Young Tim Hudson 구현한 SSL/TLS 라이브러리인 SSLeay 이용하여 Secure Socket Layer(SSL v2/v3) Transport Layer Security(TLS v1) 통한 Apache 웹서버의 강력한 암호화 기능을 제공한다.

mod_ssl package 1998 4 Ralf S. Engelschall 의하여 만들어졌으며, Ben Laurie 개발한 Apache-SSL package로부터 구현되었다. Mod_ssl Apache Group 사용한 라이센스와 동일한 BSD 스타일의 라이센스가 적용되며, author copyright 적절한 credit 표시하는 상업적, 비상업적 목적에 모두 사용될 있음을 의미한다.

Module Architecture


Mod_ssl package SSL module mod_ssl 사용하는데 필수적인 요소인 EAPI(Extended API) Apache add하기 위한 소스 패치들의 모음(set)으로 구성된다. Apache 핵심코드(core code) EAPI 포함하고 있어야만 mod_ssl 사용할 있다. 그러나 mod_ssl Apache 소스 트리에 적용할 EAPI 자동으로 add되기 때문에 보통 이것에 신경을 필요는 없으며, 이부분은 Apache 다른 package들과 mod_ssl building하고자 하는 package vendor들에게 중요한 부분이다. Mod_ssl Apache 소스 트리에 적용하는 방법에 대한 자세한 내용은 mod_ssl 배포판 안에 있는 INSTALL 파일을 참조한다.

 

Module Building

SSL module(mod_ssl) Apache 소스 트리의 src/modules/ssl 디렉토리에 위치하게 되며, 이것은 일반적인 Apache module이다. 이는 mod_ssl 다른 Apache module처럼 configure, build, install 있음을 의미한다. 보통 과정은 APACI command 사용하여 수행된다.

$ cd apache_1.3.x/

$ SSL_BASE=/path/to/ssleay ./configure --enable-module=ssl

혹은 src/Configuration 파일에서 SSB_BASE 변수를 직접 수정하고 해당 AddModule directive 주석처리를 없앤 후에 다음의 명령으로 수행할 수도 있다.

$ cd apache_1.3.x/src

$ ./Configure

다른 방법으로 APACI configure command line에서 ?enable-shared=ssl 옵션을 주거나 src/Configuration 파일에서 AddModule ssl_module module/ssl/libssl.a 라인을 SharedModule ssl_module modules/ssl/libssl.so 수정함으로써 Dynamic Shared Object(DSO) 지원을 가능하게 있다.

Mod_ssl DSO building하는 것은 run-time flexibility 향상시킬 있는데 예를 들면 build-time 아니라 run-time에서 SSL 사용할 것인가 사용하지 않을 것인가를 결정할 있다. 그러나 mod_ssl DSO building하는 것은 OS compiler DSO 지원하는가에 따라 달라지며, 모든 platform DSO 지원하지는 않는다.



  
Posted by Golmong
:


Apache 웹서버의 SSL 기능 추가를 위한 모듈인 mod_ssl 문서 중 2장 부분.
10년전 아르바이트로 번역한 것이지만 여전히 mod_ssl은 업데이트 중이다.

개인적으로 이 문서가 SSL (TLS)의 이해를 위한 기본적 암호 기술 지식과 SSL 자체의 구조를 가장 쉽고 간단하게 정리한 문서라 생각된다.

===============================================================

Chapter.2 Introduction

Cryptographic Techniques

SSL 이해하기 위해서는 암호화 알고리즘, 메시지 다이제스트(one-way or hash function), 전자서명에 대한 이해가 필요하다. technique들은 privacy, integrity, authentication 있어서의 basis 제공한다.

Cryptographic Algroithm

Alice 돈을 옮기기 위하여 자신의 은행에 메시지를 보낸다고 가정하자. 메시지에는 Alice 계좌번호, 송금액 등과 같은 정보가 포함되기 때문에 Alice 메시지가 private하기를 원한다. 이에 대한 해결책은 암호화 알고리즘을 사용하는 것이며, 암호화를 사용함으로써 Alice 메시지를 암호화된 형태로 전송하여 다른 사람들로 하여금 읽을 없도록 만든다.

메시지는 secret key 사용하여야만 해석되어질 있으며, key 없으면 메시지는 무용지물이 된다. 좋은 암호화 알고리즘은 공격자(intruder) 원래의 메시지로 decoding하는 것을 어렵게 만듦으로써 공격자의 수고를 가치 없게 만든다.

암호화 알고리즘에는 두가지 범주가 있다. : Conventional, Public key.

Conventional Cryptography

  • symmetric cryptography라고도 하며, 메시지의 송신자, 수신자가 동일한 key 공유하게 되며, key 메시지를 암호화하고 복호화하는데 사용되는 secret piece of information이다. key 안전하게 보관됨으로써 전송자와 수신자 이외에는 메시지를 읽지 못하게 된다. 만약 Alice 은행이 secret key 알고 있다면 그들은 서로에게 private message 전송할 있다. 그러나 통신 이전에 key private하게 공유하는 것이 문제가 있다.

Public Key Cryptography

  • asymmetric cryptography라고도 하며, 두개의 key 사용하는 알고리즘을 정의함으로써 key exchange 문제를 해결하며, 두개의 key 어느 것도 메시지를 암호화하는데 사용될 있다. 만약 하나의 키가 메시지를 암호화하는데 사용되었다면 다른 하나의 key 그것을 복호화하는데 사용되어져야 한다. 공개키 암호화는 단순히 하나의 (공개키) 공개하고 다른 하나의 (개인키) 보관함으로써 메시지를 안전하게 전달할 있게 해준다.
  • 누구나 공개키를 사용하여 메시지를 암호화할 있지만 해당되는 개인키를 가진 사람만이 메시지를 읽을 있다. 이러한 방식으로 Alice 은행의 공개키로 메시지를 암호화함으로써 키쌍의 주인인 은행으로 private message 보낼 있게 되며, 단지 은행만이 메시지를 복호화할 있다.

메시지 다이제스트

비록 Alice 자신의 메시지를 암호화함으로써 안전하게 만들 수는 있지만, 누군가가 돈을 가로채기 위하여 Alice original message 변조하거나 다른 message 바꿔치기 있다는 문제가 여전히 존재한다. Alice 메시지에 대한 무결성(integrity) 보장하는 하나의 방법은 Alice 메시지에 대한 간결한 요약(summary) 생성해서 메시지와 함께 은행으로 보내는 것이다. 메시지를 받게 되면 은행은 메시지의 summary 다시 생성해서 Alice 보낸 것과 비교하게 되며, 두개가 일치하면 메시지는 손상되지 않은 것이다.

이러한 summary 메시지 다이제스트, one-way function, 혹은 hash function이라고 부른다. Message digests are used to create short, fixed-length representations of longer, variable-length messages. 다이제스트 알고리즘은 서로 다른 메시지에 대하여 각각 유일한 다이제스트를 생성하도록 디자인되어진다. 또한 다이제스트로부터 원래의 메시지를 얻어내는 것이 매우 어렵게 되어 있으며, 동일한 다이제스트를 가지는 서로 다른 두개의 메시지를 찾는 것이 불가능하다. 따라서 어떤 메시지를 동일한 다이제스트를 가지는 다른 메시지로 바꿔치기할 가능성을 막아주게 된다.

Alice 직면하게 되는 다른 문제는 다이제스트를 은행으로 안전하게 보내는 방법이며, 문제가 해결되면 해당 메시지에 대한 무결성이 보장된다. 이를 위한 한가지 방법은 다이제스트를 전자 서명에 포함하는 것이다.

전자 서명(Digital Signatures)

Alice 은행으로 메시지를 전송하였을 은행은 공격자(intruder) Alice 계좌로부터 돈을 인출하는 것을 막기 위해 메시지가 정말로 Alice 보낸 것인가를 확인할 필요가 있다. 역할을 하는 것이 Alice 생성하여 메시지에 포함한 전자 서명이다.

전자 서명(Digital signatures) 메시지의 다이제스트와 다른 정보들(sequence number 같은) 전송자(sender) 개인키로 암호화함으로써 생성된다. 비록 누구나 전송자의 공개키를 가지고 서명을 복호화할 수는 있지만 단지 서명자만이 개인키를 알고 있을 뿐이며, 이것은 서명자만이 서명을 생성할 있음을 의미한다. 서명에 다이제스트를 포함한다는 것은 서명이 단지 메시지에 대해서만 유효함을 의미한다. 이것은 또한 누구도 다이제스트를 변경하지 못하며 서명을 없기 때문에 메시지의 무결성을 보장해준다.

Intruder 의한 가로채기(interception) 서명의 재사용을 막기 위하여 서명은 유일한 sequence number 포함하고 있으며, 이것은 은행으로 하여금 Alice 자신이 메시지를 보내지 않았다고 하는 부정하게(fraudulent) 클레임을 거는 것을 막아주게 된다. 이유는 단지 Alice만이 메시지에 서명할 있기 때문이다. 이를 부인봉쇄(non-repudiation)이라고 한다.

인증서(Certificates)

비록 Alice private message 은행으로 보내고, 메시지에 서명하고 또한 메시지의 무결성을 보장받을 있지만 여전히 Alice 자신이 정말로 은행과 통신(communicate)하고 있는가를 확인할 필요가 있다. 이것은 자신이 사용하는 공개키가 은행의 개인키와 대응되는가를 확인할 필요가 있음을 의미한다. 또한 은행 역시 메시지의 서명이 정말로 Alice 서명에 대응되는가를 확인할 필요가 있다.

만약 party 서로의 identity validate해주고 공개키를 confirm해주며, 또한 믿을 있는 agency 의해 서명된 증명서(certificate) 가진다면 그들은 자신이 생각하고 있는 올바른 상대방과 통신하고 있음을 확신할 있을 것이다. 이러한 믿을 있는 agency Certificate Authority라고 부르며, 증명서(certificate) 인증(authentication) 사용된다.

Certificate Contents

증명서는 하나의 공개키와 실재의 subject 보여지는 identity(individual, server 등등) 연관시킨다. subject 대한 정보는 identifying information(the distinguished name) 공개키를 포함한다. 또한 증명서는 증명서를 발급한 CA 대한 identification 서명, 그리고 증명서의 유효기간을 포함한다. 증명서에는 serial number 같이 CA 관리적 목적으로 사용하기 위한 administrative information 같은 부가적인 정보를 가질 수도 있다.

Subject:

Distinguished Name, Public Key

Issuer:

Distinguished Name, Signature

Period of Validity:

Not Before Date, Not After Date

Administrative Information:

Version, Serial Number

Extended Information:

Basic Contraints, Netscape Flags, etc.

Table 1: Certificate Information

Distinguished name 특정한 context 내에서 identity 제공하기 위해 사용된다. 예를 들어, 개인(individual) 개인 증명서(personal certificate) 뿐만 아니라 하나의 employee로서의 증명서을 가진다. Distinguished name X.509 표준[X509] 정의되어 있으며, 여기에는 field, field name, abbreviation(약어) 정의되어 있다.

A distinguished name is used to provide an identity in a specific context ? for instance, an individual might have a personal certificate as well as one for their identity as an employee. Distinguished names are defined by the X.509 standard [X509], which defines the fields, field names, and abbreviations used to refer to the fields (see Table 2).

DN Field:

Abbrev.:

Description:

Example:

Common Name

CN

Name being certified

CN=Joe Average

Organization or

Company

O

Name is associated with this organization

O=Snake Oil, Ltd.

Organizational Unit

OU

Name is associated with this organization unit, such as a department

OU=Research Institute

City/Locality

L

Name is located in this City

L=Snake City

State/Province

ST

Name is located in this State/Province

ST=Desert

Country

C

Name is located in this Country (ISO code)

C=XZ

Table 2: Distinguished Name Information

CA 어떤 DN name 필수적(required)이냐, 부가적(optional)이냐를 명시하는 정책(policy) 정의할 있으며, 또한 필드의 내용(field content) 대한 요구사항(requirement) 포함할 있다. 예를 들면, Netscape 브라우져는 어떤 서버에 대한 증명서의 Common Name 서버의 도메인 네임에 대한 wildcard pattern ( *.snakeoil.com 같은…) 부합(match)되는 이름을 가질 것을 요구한다.

증명서의 binary format ASN.1 notation [ X208] [PKCS] 사용하여 정의한다. notation content information binary form으로 변환하는 방법을 정의하는 encoding rule들을 어떻게 specify하는가를 정의한다. 증명서의 binary encoding Distinguished Encoding Rules(DER) 사용하여 정의하며, DER 일반적인 Basic Encoding Rules(BER) 기반을 두고 있다. Binary 다루지 못하는(cannot handle) transmission 위하여 binary form Base64 encoding [MIME] 사용하여 ASCII form으로 변환될 수도 있다. 이렇게 encoding 버전을 PEM(“Privacy Enhanced Mail”에서 얻어진 이름) encoded라고 부르며, [Table3]에서와 같이 begin delimiter line end delimiter line 사이에 놓여진다.

-----BEGIN CERTIFICATE-----

MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx

FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG

A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv

cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz

bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL

MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h

a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl

cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN

AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB

gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b

vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa

lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV

HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB

gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt

2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7

dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==

-----END CERTIFICATE-----

Table 3: Example of a PEM-encoded certificate (snakeoil.crt)

인증기관(Certificate Authorities)

CA 증명서를 발급하기 전에 먼저 증명서에 있는 정보를 확인(verify)함으로써 키쌍의 개인키의 identity 확인(assure)한다. 예를 들어 만약 Alice 개인 증명서(personal certificate) 요청하는 경우 CA 반드시 먼저 Alice 정말로 증명서를 요청한 사람인가를 확인하여야 한다.

Certificate Chains

CA 다른 CA 대한 증명서을 발급(issue) 있다. 증명서를 examining Alice Alice 신뢰할 있는 CA 도달할 때까지 parent CA 대한 issuer 증명서를 examine해야 필요가 있을 있다. Alice chain안의 “bad” certificate 대한 위험을 줄이기 위하여 제한된 chain(limited chain of issuers) 가진 증명서만을 신뢰할 것을 결정할 수도 있다.

Creating a Root-Level CA

위에서 언급된 바와 같이, certificate들은 top-level CA 도달할 때까지 certificate subject identity 대한 유효성(validity) certificate issuer 보증해야 한다. 이것은 하나의 문제를 발생시키는데, 그것은 issuer 가지지 않는 top-level authority certificate 누가 보증하는가의 문제이다. 이런 특정한 경우, top-level authority certificate “self-signed”되어지며, 증명서의 issuer subject 동일하게 된다. 결과로서 self-signed certificate 신뢰에 대한 문제가 생긴다. Root authority 의한 공개키의 wide publication 공개키의 신뢰에 대한 위험을 줄여줄 있는데, 누군가가 자신이 authority 되겠다고 하면서 키를 공표함으로써 문제를 해결할 있다. 보통 브라우져들은 well-known CA들을 신뢰할 있도록 미리 설정되어있다(preconfigured).

Thawte이나 VeriSign 같은 몇몇 회사들이 자신을 Certificate Authority로서 입지를 굳혀왔으며, 이들은 다음과 같은 서비스를 제공한다:

  • 증명서 요청에 대한 확인(Verifying certificate requests)
  • 증명서 요청의 처리(Processing certificate requests)
  • 증명서의 발급과 관리(Issuing and managing certificates)

자기 자신만의 CA(one’s own CA) 생성하는 것도 가능한데, 비록 인터넷 환경에서는 위험하긴 하지만 어떤 조직 내에서 개인이나 서버들을 확인(verify)하기 위한 목적의 인트라넷 환경에서는 매우 유용할 있다.

Certificate Management

CA 설립(establishing)하는 것은 믿을 있는 관리적(administrative), 기술적(technical), 관리(management) framework 요구하는 일이다. CA 증명서를 발급할 뿐만 아니라 증명서를 관리해야 한다. , 증명서가 어느 기간 동안 유효한가를 결정하고, 증명서를 갱신하며, 발급은 되었지만 이상 유효하지 않은 증명서들의 리스트(Certificate Revocation Lists - CRL) 관리해야 한다. 만약 Alice에게 어떤 회사의 직원으로서의 증명서를 발급하였다면 Alice 회사를 떠날 증명서는 취소되어야 필요가 있다. 그러나 증명서는 돌아다니는 것이기 때문에 증명서 자체만으로는 그것이 취소되었다는 것을 알려줄 없다. 따라서 증명서의 유효성(validity) 확인하고자 CRL 체크하기 위해서 증명서를 발급한 CA 문의(contact) 필요가 있다(보통 이것은 자동으로 되는 프로세스가 아니다-- this is not usually an automated part of the process).

Note:

브라우져에 디폴트로 설정되어져 있지 않은 CA 사용하는 경우, 브라우져로 하여금 CA 서명한 server certificate 확인(validate) 있도록 하기 위해 CA certificate 브라우져에 load해야 하는데, 이것은 브라우져가 일단 한번 CA certificate load하면 CA 서명한 모든 certificate 받아들이게 되기 때문에 위험할 있다.

 

Secure Sockets Layer (SSL)

Secure Sockets Layer protocol Reliable connection-oriented network layer protocol (e.g. TCP/IP) Application protocol layer (e.g. HTTP) 사이에 위치하는 Protocol Layer이다. SSL 상호 인증, 무결성을 위한 전자 서명의 사용, privacy 위한 암호화 등을 이용하여 클라이언트와 서버간의 안전한 통신을 제공한다.

프로토콜은 암호화, 다이제스트, 서명을 위한 특정 알고리즘의 선택을 지원하도록 디자인되어졌다. 이것은 특정 서버의 알고리즘 선택이 법적인 문제나 수출법과 같은 문제에 기반하여 이루어질 있도록 해주며, 또한 프로토콜로 하여금 새로운 알고리즘의 채택을 가능하게 해준다. 알고리즘의 선택은 프로토콜 세션이 시작될 클라이언트와 서버 간에 협상(negotiation)된다.

Version:

Source:

Description:

Browser Support:

SSL v2.0

Vendor Standard

(from Netscape Corp.)

[SSL2]

First SSL protocol for which implementations exists

- NS Navigator 1.x/2.x

- MS IE 3.x

- Lynx/2.8+SSLeay

SSL v3.0

Expired Internet Draft

(from Netscape Corp.)

[SSL3]

Revisions to prvent specific security attacks, add non-RSA ciphers, and support for certificate chains

- NS Navigator 2.x/3.x/4.x

- MS IE 3.x/4.x

- Lynx/2.8+SSLeay

TLS v1.0

Proposed Internet Standard

(from IETF)

[TLS1]

Revision of SSL 3.0 to update the MAC layer to HMAC, add block padding for block ciphers, message order standardization and more alert messages.

- Lynx/2.8+SSLeay

Table 4: Versions of the SSL protocol

[Table 4] 보여지는 바와 같이 몇가지 버전의 SSL 프로토콜이 있다. 위에 기술된 바처럼, SSL 3.0 장점 하나는 certificate chain loading 지원한다는 것이며, 이것은 서버가 브라우져에게 issuer certificate 함께 서버의 certificate 넘겨주는 것을 가능하게 해준다. 또한 Chain loading 기능은 해당 서버 certificate 서명한 issuer CA certificate 브라우져에 설치되어 있지 않은 경우에도 server certificate certificate chain 포함되어 있기 때문에 브라우져가 server certificate 확인(validate) 있도록 해준다. Transport Layer Security [TLS] protocol standard SSL 3.0 기반으로 하였으며, 현재 Internet Engineering Task Force (IETF) 의해 개발되고 있다.

Session Establishment

SSL 세션은 [Figure 1]에서와 같이 클라이언트와 서버 간의 handshake sequence 따라 이루어진다. sequence 서버가 server certificate 제공하느냐, 혹은 client certificate 요구하는가에 따라 달라질 있다. Cipher information 관리를 위해 부가적인 handshake step 요구되는 경우도 존재하지만 여기서는 하나의 일반적인 시나리오를 정리한다: 가능한 모든 경우에 대한 설명은 SSL specification 참조하라

Note

일단 SSL 세션이 이루어지면 이것은 재사용되어질 있으며, 이로 인하여 세션을 시작하기 위해 필요한 많은 단계들을 반복함으로써 발생하는 performance penalty 피할 있다. Reusing 기능을 위하여 서버는 SSL 세션마다 유일한 session identifier 할당하며, identifier 서버에 저장되어서 이후에 클라이언트가 다시 연결할 이를 사용함으로써 handshake 줄일 있다(session identifier 서버의 캐쉬에서 지워지기 이전까지 사용할 있다).

Figure 1: Simplified SSL Handshake Sequence

Handshake sequence 요소는 다음과 같다.

  1. 데이터 전송 시에 사용할 Cipher Suite 협상(negotiation)한다.( Negotiate the Cipher Suite to be used during data transfer)
  2. 클라이언트와 서버 간의 세션키를 공유한다.( Establish and share a session key between client and server)
  3. 부가적으로(Optionally) 클라이언트에게 서버를 인증한다.(authenticate the server to the client)
  4. 부가적으로(Optionally) 서버에게 클라이언트를 인증한다.(authenticate the client to the server)

첫번째 단계인 Cipher Suite Negotiation에서 클라이언트와 서버는 양측 모두가 지원할 있는 Cipher Suite 선택한다. SSL 3.0 프로토콜 규격은 31개의 Cipher Suite 정의되어 있다. 하나의 Cipher Suite 다음의 요소들로 정의된다:

  • Key Exchange Method
  • Cipher for Data Transfer
  • Message Digest for creating the Message Authentication Code (MAC)

Key Exchange Method

Key exchange method 어플리케이션 데이터의 전송에 사용할 공유 비밀키를 어떻게 클라이언트와 서버간에 동의(agree) 것인가를 정의한다. SSL 2.0 RSA 교환만을 지원하지만 SSL 3.0 가지 교환 알고리즘(RSA key exchange, Diffie-Hellman key exchange) 중에 선택할 있도록 지원한다. RSA 교환은 certificate 사용되는 경우에 선택되며, Diffie-Hellman 교환은 certificate 없고 클라이언트와 서버 간의 통신이 이전에 한번도 없는 경우에 선택된다.

Key exchange method 선택에 있어서 하나의 변수는 전자 서명을 사용할 것인가 사용하지 않을 것인가, 그리고 사용한다면 어떤 종류의 서명을 사용할 것인가이다. 개인키를 이용한 서명을 사용함으로써 공유키를 생성하는데 사용되는 정보를 교환할 man-in-the-middle-attack 막을 있다 [AC96, p516].

Cipher for Data Transfer

SSL 세션 내의 메시지를 암호화하기 위해서 위에서 기술된 conventional cryptography algorithm(대칭형 암호화) 사용한다. 암호화를 하지 않는 경우를 포함해서 9가지의 선택이 가능하다:

No encryption

Stream Ciphers

    • RC4 with 40-bit keys
    • RC4 with 128-bit keys

CBC Block Ciphers

    • RC2 with 40 bit key
    • DES with 40 bit key
    • DES with 54 bit key
    • Triple-DES with 168 bit key
    • Idea (128 bit key)
    • Fortezza (96 bit key)

“CBC” Cipher Block Chaining 의미하며, 모드에서는 바로 이전에 암호화된 암호문의 일부가 현재 block 암호화에 사용되어진다. “DES” Data Encryption Standard 의미하며, 여러가지의 variant(DES40, 3DES_EDE) 있다. "Idea" 암호학적으로 가장 강력한 알고리즘이며, "RC2" RSA DSI에서 개발한 독점적인 알고리즘이다.

Digest Function

Digest Function 선택은 record unit으로부터 어떻게 다이제스트가 생성되어지는가를 결정하며, SSL 다음을 지원한다:

  • No digest (Null choice)
  • MD5, a 128-bit hash
  • Secure Hash Algorithm (SHA-1), a 160-bit hash

메시지 다이제스트는 Message Authentication Code (MAC) 생성하는데 사용된다. MAC 메시지와 함께 암호화됨으로써 메시지의 무결성을 제공하며 또한 replay attack 막아준다.

Handshake Sequence Protocol

Handshake sequence 가지의 프로토콜을 사용한다:

  • The SSL Handshake Protocol for performing the client and server SSL session establishment.
  • The SSL Change Cipher Spec Protocol for actually establishing agreement on the Cipher Suite for the session.
  • The SSL Alert Protocol for conveying SSL error messages between client and server.

These protocols, as well as application protocol data, are encapsulated in the SSL Record Protocol, as shown in Figure 2. An encapsulated protocol is transferred as data by the lower layer protocol, which does not examine the data. The encapsulated protocol has no knowledge of the underlying protocol.

Figure 2: SSL Protocol Stack

The encapsulation of SSL control protocols by the record protocol means that if an active session is renegotiated the control protocols will be transmitted securely. If there were no session before, then the Null cipher suite is used, which means there is no encryption and messages have no integrity digests until the session has been established.

Data Transfer

SSL Record Protocol application data SSL Control data 작은 unit 쪼개거나, multiple higher level protocol data message 하나의 unit 결합하여 클라이언트와 서버 간에 전송한다. It may compress, attach digest signatures, and encrypt these units before transmitting them using the underlying reliable transport protocol (Note: currently all major SSL implementations lack support for compression).

Figure 3: SSL Record Protocol

Securing HTTP Communication

SSL 보통 브라우져와 서버 간의 HTTP 통신을 안전하게 만드는데 사용되며, 경우 non-secure HTTP 사용하지 않는 것이 아니라, SSL 위에서 일반적인 plain HTTP 구현한다(HTTPS라고 한다). 한가지 중요한 차이는 HTTPS 이용할 http 다른 서버 포트(디폴트 443) 사용하는 것이 아니라 https라는 URL scheme 사용한다는 것이며, 이것이 mod_ssl Apche 웹서버에 제공하는 주요한 기능이다.

References

[AC96] Bruce Schneier, Applied Cryptography, 2nd Edition, Wiley, 1996. See

http://www.counterpane.com/ for various other materials by Bruce Schneier.

[X208] ITU-T Recommendation X.208, Specification of Abstract Syntax Notation One (ASN.1), 1988.

See for instance ftp://ftp.neda.com/pub/itu/x.series/x208.ps.

[X509] ITU-T Recommendation X.509, The Directory ? Authentication Framework, 1988.

See for instance ftp://ftp.bull.com/pub/OSIdirectory/ITUnov96/X.509/97x509final.doc.

[PKCS] Kaliski, Burton S., Jr., An Overview of the PKCS Standards, An RSA Laboratories Technical Note, revised November 1, 1993. See http://www.rsa.com/rsalabs/pubs/PKCS/.

[MIME] N. Freed, N. Borenstein, ultipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, RFC2045. See for instance ftp://ftp.isi.edu/in-notes/rfc2045.txt.

[SSL2] Kipp E.B. Hickman, The SSL Protocol, 1995.

See http://www.netscape.com/eng/security/SSL_2.html.

[SSL3] Alan O. Freier, Philip Karlton, Paul C. Kocher, The SSL Protocol Version 3.0, 1996. See

http://www.netscape.com/eng/ssl3/draft302.txt.

[TLS1] Tim Dierks, Christopher Allen, The TLS Protocol Version 1.0, 1997. See

ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-protocol-06.txt.

Posted by Golmong
: