0. 필요성 및 문제점?
1) 필요성
요즘 개인정보 보호를 위해서 인증서 설치가 필수가 되었다.
왜냐면? 패킷을 분석해 보면 id, 비밀번호, 주민번호 기타 개인정보가 다 보인다는 것이며, 이를 보호하기 위해서 패킷을 암호화 하는 ssl 을 사용해야 한다고 한다...
2) 문제점
하지만, ssl특성상 가상호스트를 지원하지 않는다. 왜냐하면? 가상호스트는 http헤더에 붙어서 나오고 웹서버에서 이 헤더의 "Host : " 부분을 참조하여 호스트를 결정한다. ssl은 헤더를 읽기도 전에, 인증서교환이 선행된다. 인증서 교환은 아이피,포트를 통해서 접속하므로 이름기반 가상호스트를 지원하지 않는다.
3) SSL의 인증과정 (조금 생략)
1. 클라이언트는 https(SSL)을 사용하여 서버에 접속한다. IP와 포트정보를 가지고
2. 서버는 클라이언트에게 인증서를 제공한다.
3. 클라이언트는 인증서를 평가한다. CN과 입력한 호스트 이름을 비교한다.
맞으면 진행, 틀리면 경고창을 내보낸다.
4. 3번항목에서 맞다면, 대칭키를 하나 생성한다.(대부분 128비트, 256비트)
5. 생성된 대칭키를 인증서의 공개키로 암호화 해서 서버로 보낸다.
공개키로 암호화 한 대칭키는 서버의 공개키로만 해독 할 수 있다.
6. 서버에 대칭키가 도달되면, 이 대칭키로 통신을 계속 하게 된다.
(주의!. 위 과정이 전부는 아님.. 간소화 하였음)
1. 가상호스트 문제점 해결법?
HTTP 1.1 프로토콜에서는 헤더를 이용하여 가상호스트를 지원한다. 하지만, SSL은 TCP/IP 계층의 더 하위 계층에서 암호화 해 버리기 때문에 가상호스트를 지원하지 않는다.
SSL은 TCP/IP의 응용계층과 전송계층 사이에서 클라이언트와 서버간의 안전한 통신을 위해 암호화 한다.
전송계층에서 목적지가 결정되기 때문에, 가상호스트는 불가능 하다.
참고
응용 계층 프로토콜 : FTP, HTTP, IMAP, IRC, NNTP, POP3 등...
전송 계층 프로토콜 : TCP, UDP, SCTP, DCCP ...
웹에서 사용하는 HTTP는 TCP를 사용한다.
1) 포트를 이용한 SSL 가상호스트
브라우져에서 접속할때, 포트를 다르게 하면, 다중 도메인 지원이 가능하다.
포트가 다르다는 것은 전송계층의 프로토콜인 TCP에서 지원 가능하다.
아파치의 ssl.conf파일을 여러개 만들어서 포트를 다르게 하면, 쉽게 설정 가능하다.
단지 불편하다면, 웹브라우져에서 접속 할 때
https://도메인:포트 <== 이렇게 붙여 주어야 하는 불편함이 있다.
2) 아이피를 이용한 SSL 가상호스트
아이피 기반의 가상호스트 설정은 물론 가능한 방법이다.
3) 하나의 인증서를 이용하여 여러개 도메인 인증
하나의 인증서에 여러개의 CM(Common Name)이 등록되어 있다면, SSL 가상 호스트가 적용된다.
이는 이미 SSL 인증서 교환이 이뤄지고, SSL 가상 호스트를 통하여 적용 된다.
참고
(openssl에서, 하나의 인증서에 여러개의 CN 넣기)
openssl.cnf 파일을 열어서 편집한다.
2. 잡담
이제 SSL 적용은 선택이 아니라 필수가 되었다.
이미 미국, 일본에서는 적용되었으며, 보안에 대한 의식도 높다..
보안을 위해 다음것도 지켜줘야 한다.
Telnet 대신 SSH를 사용한다.
FTP대신 SFTP를 사용한다.
1) 필요성
요즘 개인정보 보호를 위해서 인증서 설치가 필수가 되었다.
왜냐면? 패킷을 분석해 보면 id, 비밀번호, 주민번호 기타 개인정보가 다 보인다는 것이며, 이를 보호하기 위해서 패킷을 암호화 하는 ssl 을 사용해야 한다고 한다...
2) 문제점
하지만, ssl특성상 가상호스트를 지원하지 않는다. 왜냐하면? 가상호스트는 http헤더에 붙어서 나오고 웹서버에서 이 헤더의 "Host : " 부분을 참조하여 호스트를 결정한다. ssl은 헤더를 읽기도 전에, 인증서교환이 선행된다. 인증서 교환은 아이피,포트를 통해서 접속하므로 이름기반 가상호스트를 지원하지 않는다.
3) SSL의 인증과정 (조금 생략)
1. 클라이언트는 https(SSL)을 사용하여 서버에 접속한다. IP와 포트정보를 가지고
2. 서버는 클라이언트에게 인증서를 제공한다.
3. 클라이언트는 인증서를 평가한다. CN과 입력한 호스트 이름을 비교한다.
맞으면 진행, 틀리면 경고창을 내보낸다.
4. 3번항목에서 맞다면, 대칭키를 하나 생성한다.(대부분 128비트, 256비트)
5. 생성된 대칭키를 인증서의 공개키로 암호화 해서 서버로 보낸다.
공개키로 암호화 한 대칭키는 서버의 공개키로만 해독 할 수 있다.
6. 서버에 대칭키가 도달되면, 이 대칭키로 통신을 계속 하게 된다.
(주의!. 위 과정이 전부는 아님.. 간소화 하였음)
1. 가상호스트 문제점 해결법?
HTTP 1.1 프로토콜에서는 헤더를 이용하여 가상호스트를 지원한다. 하지만, SSL은 TCP/IP 계층의 더 하위 계층에서 암호화 해 버리기 때문에 가상호스트를 지원하지 않는다.
SSL은 TCP/IP의 응용계층과 전송계층 사이에서 클라이언트와 서버간의 안전한 통신을 위해 암호화 한다.
전송계층에서 목적지가 결정되기 때문에, 가상호스트는 불가능 하다.
참고
응용 계층 프로토콜 : FTP, HTTP, IMAP, IRC, NNTP, POP3 등...
전송 계층 프로토콜 : TCP, UDP, SCTP, DCCP ...
웹에서 사용하는 HTTP는 TCP를 사용한다.
1) 포트를 이용한 SSL 가상호스트
브라우져에서 접속할때, 포트를 다르게 하면, 다중 도메인 지원이 가능하다.
포트가 다르다는 것은 전송계층의 프로토콜인 TCP에서 지원 가능하다.
아파치의 ssl.conf파일을 여러개 만들어서 포트를 다르게 하면, 쉽게 설정 가능하다.
단지 불편하다면, 웹브라우져에서 접속 할 때
https://도메인:포트 <== 이렇게 붙여 주어야 하는 불편함이 있다.
2) 아이피를 이용한 SSL 가상호스트
아이피 기반의 가상호스트 설정은 물론 가능한 방법이다.
3) 하나의 인증서를 이용하여 여러개 도메인 인증
하나의 인증서에 여러개의 CM(Common Name)이 등록되어 있다면, SSL 가상 호스트가 적용된다.
이는 이미 SSL 인증서 교환이 이뤄지고, SSL 가상 호스트를 통하여 적용 된다.
참고
(openssl에서, 하나의 인증서에 여러개의 CN 넣기)
openssl.cnf 파일을 열어서 편집한다.
[ req_distinguished_name ]0.commonName = CommonName
0.commonName_default = www.first-domain.com
0.commonName_max = 641.commonName = CommonName
1.commonName_default = www.second-domain.com
1.commonName_max = 64
( 위와같은 방법으로 CN 추가 )
문제점?
멀티 인증서는 문제점을 가지고 있다.
1. 인증서 관리의 불편함(도메인 중 하나를 변경하려면 인증서 갱신)
2. 브라우져와의 호환성 떨어짐. (아래 표 참고)
| 웹브라우져 |
호환 버젼 | 호환되지 않는 버전 |
|---|---|---|
| 사파리 |
1.2.4 | |
| OmniWeb | 5.0.1 | |
| 인터넷익스플로러(Mac OS X) | 5.2 | |
| Chimera | 0.2.8 | |
| 모질라 |
1.4 |
2. 잡담
이제 SSL 적용은 선택이 아니라 필수가 되었다.
이미 미국, 일본에서는 적용되었으며, 보안에 대한 의식도 높다..
보안을 위해 다음것도 지켜줘야 한다.
Telnet 대신 SSH를 사용한다.
FTP대신 SFTP를 사용한다.
출처 : http://www.linux.co.kr/blog2/doly/entry/한-서버에-여러개의-ssl-인증서-사용-하는-방법
