HTTPS와 SSL인증서 (3)SSL 통신과정, startssl
---
SSL 통신 과정
---
클라이언트와 서버가 통신할 때 가장 이상적인 방법은 공개키 방식으로 통신하는 것.
클라이언트와 서버가 각자 서로의 공개키를 서로에게 주고, 서로의 공개키로 암호화해서 보내는 것.
하지만 암호화하고 복호화하는 과정에서 컴퓨팅 파워를 많이 쓰는게 단점이라 안쓴다
---
(여기서부턴 그냥 opentutorials내용 섞어서 내가 정리)
SSL의 동작 방법
결론부터 말하면 SSL은 암호화된 데이터를 전송하기 위해서 공개키와 대칭키를 혼합해서 사용한다. --공개키만 쓰는 것보다 성능up
즉 클라이언트와 서버가 주고 받는 실제 정보는 대칭키 방식으로 암호화하고, 대칭키 방식으로 암호화된 실제 정보를 복호화할 때사용할 대칭키는 공개키 방식으로 암호화해서 클라이언트와 서버가 주고 받는다.
- 실제 데이터 : 대칭키 --대칭키 방식은 공개키 방식에 비해서 컴퓨팅 파워를 덜 쓴다
- 대칭키의 키 : 공개키 --양쪽 다 대칭키의 키를 공유하고 있어야 한다.
이 방식은 네트워크를 통해 구현한다
---
컴퓨터와 컴퓨터가 네트워크를 이용해서 통신을 할 때는 내부적으로 3가지 단계가 있다. 아래와 같다.
악수 -> 전송 -> 세션종료
이것은 은밀하게 일어나기 때문에 사용자에게 노출되지 않는다. 이 과정에서 SSL가 어떻게 데이터를 암호화해서 전달하는지 살펴보자.
1.악수 : 인사, 가장 복잡하고 중요하다
2.전송(세션이라고도 한다) : id, pw, 기밀정보 등을 주고받는게 이 두번째 단계
3.세션 종료
---
1. 악수 (handshake)
사람과 사람이 소통을 할 때를 생각해보자.(--네트워크 통신과 유사) 우선 인사를 한다.(--얼굴보자마자 내용 이야기를 하지 않고, 또 인사할 때 우리도 모르게 중요한 정보를 주고 받는다) 인사를 통해서 상대의 기분과 상황을 상호탐색을 하는 것이다. (--무슨 언어를 쓰는지, 교육 수준..)이 과정이 잘되야 소통이 원활해진다.
클라이언트와 서버 사이도 마찬가지다. 실제 데이터를 주고 받기 전에 클라이언트와 서버는 일종의 인사인 Handshake(진짜로 사용하는 기술용어다)를 한다. 이 과정을 통해서 서로 상대방이 존재하는지, 또 상대방과 데이터를 주고 받기 위해서는 어떤 방법을 사용해야하는지를 파악한다.(--서버와 클라이언트는 단일한 환경이 아냐, 오래된 브라우저일 수도, 서버도 오래된 웹서버가 있는가하면 최신 웹서버도 있고.. 핸드 쉐이크를 통해 클라이언트는 서버를, 서버는 클라이언트를 파악하는 과정을 거친다)
SSL 방식을 이용해서 통신을 하는 브라우저와 서버 역시 핸드쉐이크를 하는데,
이 때 서버의 SSL 인증서를 클라이언트에게 준다(가장 중요).
또 클라이언트가 해독할 수 있는 암호화 기법, 서버가 처리할 수 있는 암호화 기법을 서로 교환하는 것도 이 단계에서 하는 가장 중요한 일
인증서에 포함된 서버 측 공개키의 역할은 무엇일까를 이제 알아보자. SSL은 공개키와 대칭키의 장점을 혼합한 방법을 사용한다.(전에 설명) 그 핸드쉐이크 단계에서 클라이언트와 서버가 통신하는 과정을 순서대로 살펴보자.
1.
클라이언트가 서버에 접속한다(웹브라우저에 엔터를 치는 순간). 이 단계를 Client Hello라고 한다.(말이 웃기죠) 이 단계에서 주고 받는 정보는 아래와 같다.
- 클라이언트 측에서 생성한 랜덤 데이터 : 아래 3번 과정 참조, 당장은 그냥 랜덤 데이터 전송한다고만
- 클라이언트가 지원하는 암호화 방식들을 서버쪽에 전송 : 클라이언트가 다 다르고 암호화기법도 발전해. 클라이언트와 서버가 지원하는 암호화 방식이 서로 다를 수 있기 때문에 상호간에 어떤 암호화 방식을 사용할 것인지에 대한 협상을 해야 한다.
- 세션 아이디 : (안설명)이미 SSL 핸드쉐이킹을 했다면 비용과 시간을 절약하기 위해서 기존의 세션을 재활용하게 되는데 이 때 사용할 연결에 대한 식별자를 서버 측으로 전송한다.
2.
서버는 Client Hello에 대한 응답으로 Server Hello를 하게 된다. 이 단계에서 주고 받는 정보는 아래와 같다.
- 서버 측에서 생성한 랜덤 데이터 : 아래 3번 과정 참조(뒤에서)
- 서버가 선택한 클라이언트의 암호화 방식 : 클라이언트가 전달한 암호화 방식 중에서 서버 쪽에서도 사용할 수 있으면서 가장 안전한 암호화 방식을 선택해서 클라이언트로 전달한다. 이로써 암호화 방식에 대한 협상이 종료되고 서버와 클라이언트는 이 암호화 방식을 이용해서 정보를 교환하게 된다.
- 인증서를 전송한다
3.
클라이언트는 서버가 전송한 인증서가 어떤 루트 CA에 의해서 발급된 것인지를 확인하고, 클라이언트에 내장된 CA 리스트에 있는지 확인한다. CA 리스트에 인증서가 없다면 사용자에게 경고 메시지를 출력한다. 있다면 인증서가 CA에 의해서 발급된 것인지를 확인하기 위해서 클라이언트에 내장된 CA의 공개키를(이미 갖고 있다) 이용해서 인증서를 복호화한다. 복호화에 성공했다면 인증서는 CA의 개인키로 암호화된 문서임이 암시적으로 보증된 것(내가 접속한 서비스가 인증된 기관에 의해 보장된 것을 브라우저가 알 수 있게 됨)이다. 인증서를 전송한 서버를 믿을 수 있게 된 것이다.
인증서 안에는 서버가 생성한 공개키가 들어있는데, 이 단계에서 클라이언트가 서버의 공개키를 획득한다
클라이언트는 상기 2번을 통해서 받은 서버의 랜덤 데이터와 클라이언트가 생성한 랜덤 데이터를 조합해서 pre master secret라는 키를 생성한다. 이 키는 뒤에서(hand shake가 끝나고) 살펴볼 세션 단계(실제로 데이터는 전송하는 단계)에서 데이터를 주고 받을 때 대칭키로 암호화하기 위해서 사용될 것이다. 대칭키이기 때문에 pre master secret 값은 제 3자에게 절대로 노출되어서는 안된다.
근데 랜덤 데이터를 보낼 때 그냥 보내면 중간에 누군가가 가로챌 수가 있다. 그럼 문제는 이 pre master secret 값을 어떻게 서버에게 전달할 것인가이다.
이걸 방지하기 위해 사용하는것이 인증서 안에 있던 서버의 공개키고 이 때 사용하는 방법이 바로 공개키 방식이다. 서버의 공개키로 pre master secret 값을 암호화해서 서버로 전송하면 서버는 자신의 비공개키로 안전하게 복호화 할 수 있다. 전송한 내용이 유출되더라도 pre master secret값을 암호화한 것에 대한 비밀키는 서버만 갖고 있어서 복호화 할 수 있는 건 서버만 할 수 있다. 서버의 공개키는 서버로부터 받은 인증서 안에 들어있다. 이 서버의 공개키를 이용해서 pre master secret 값을 암호화한 후에 서버로 전송하면 안전하게 전송할 수 있다.
4.
서버는 클라이언트가 전송한 pre master secret 값을(안전하게 도착) 자신의 비공개키로 복호화한다. 이로서 서버와 클라이언트가 모두 pre master secret 값을 공유하게 되었다. 이 둘만 알아
그리고 서버와 클라이언트는 모두 일련의 과정을 거쳐서 pre master secret 값을 master secret 값으로 만든다.
master secret는 최종적으로 session key를 생성하는데 이 session key 값을 이용해서 (핸드세이킹의 다음 단계에서) 서버와 클라이언트는 데이터를 대칭키 방식으로 암호화 한 후에 주고 받는다. 이렇게해서 세션키를 클라이언트와 서버가 모두 공유하게 되었다는 점을 기억하자.
▽맨 처음에 클라가 랜덤데이터 값을 보내고
그 다음 서버의 랜덤 데이터를 받고,
pre master secret값을 만들고
이걸 서버의 공개키로 암호화하고
서버가 이걸 복호화
->아니 그럼 처음에 클라이언트는 랜덤 데이터를 왜 보냈어? 뭐 이유가 있겠지
5.
클라이언트와 서버는 핸드쉐이크 단계의 종료를 서로에게 알린다.
핵심 :
인증서를 서버가 클라이언트에게 전송
클라이언트는 인증서 안에 담겨있는 공개키를 이용해서 랜덤으로 생성한 어떤 값을 암호화하고 그 공개키의 비밀키를 갖고 있는 서버로 전송.
서버는 전송된 랜덤값을 복호화해서
그 다음부터 서버와 클라이언트가 서로 통신할 때 사용할 세션키를(쌍방이 똑같은) 갖게 되는 것
---
2. 세션
(별게 없다)
세션은 실제로 서버와 클라이언트가 데이터를 주고 받는 단계이다.
이 단계에서 핵심은 정보를 상대방에게 전송하기 전에 session key 값을 이용해서 대칭키 방식으로 암호화 한다는 점이다. 암호화된 정보는 상대방에게 전송될 것이고, 상대방도 세션키 값을 알고 있기 때문에 암호를 복호화 할 수 있다.
서버는 복호화해서 처리를 하고 결과를 다시 세션키를 이용해서 암호화해서 클라이언트로 전송
...
공개키 방식이 이상적이지만, 많은 컴퓨터 파워를 사용한다. 만약 공개키를 그대로 사용하면 많은 접속이 몰리는 서버는 매우 큰 비용을 지불해야 할 것이다. 반대로 대칭키는 암호를 푸는 열쇠인 대칭키를 상대에게 전송해야 하는데, 암호화가 되지 않은 인터넷을 통해서 키를 전송하는 것은 위험하기 때문이다. 그래서 속도는 느리지만 데이터를 안전하게 주고 받을 수 있는 공개키 방식으로 대칭키를 암호화하고, 실제 데이터를 주고 받을 때는 대칭키를 이용해서 데이터를 주고 받는 것이다.
---
3. 세션종료
데이터의 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알려준다. 이 때 통신에서 사용한 대칭키인 세션키를 폐기한다.
혹시나 세션키가 노출돼서 암호를 역으로 추정하는 작업을 한다고 해도 세션의 수립과 종료는 아주 짧은 시간에 일어나는 작업이라 그동안 암호가 해독된다고 해도 이미 세션은 종료가 돼 있는 상태라는 것이 SSL인증방식의 특성
---
StartSSL(이 사이트 없어짐, 그냥 뭐하는지 보기)
---
이제 실무를 해보자. 어떻게 인증서를 구입하고 어떻게 서버에 세팅하는가
---
(opentutorials내용)
수업에서 필자의 착오로 startssl을 starssl이라고 언급하고 있다. startssl이 맞는 브랜드 이름이다.
2009년 이전의 XP나 비스타와 같은 운영체제에서는 startssl이 공인된 인증서로 등록 되어 있지 않을 수 있다. 물론 사용자가 업데이트를 충실히 했다면 그런 문제는 발생하지 않는다.
CA(인증기관)를 통해서 구입하고 사용하는 방법 알아보기
지금부터는 CA를 통해서 인증서를 구입해서 사용하는 방법을 알아보자. 앞서 언급한 것처럼 CA는 인증서를 발급해주는 기관이다. 이 기관들을 통해서 인증서를 구입함으로서 사용자들에게 좀 더 안전한 서비스를 제공할 수 있다. 인증서를 구입하는 것부터 설치하는 방법까지 알아보자.
CA는 기업이다. 따라서 어떤 기업을 선택할 것인지를 각자가 충분히 숙고해서 판단해야 한다. 위키피디아에는 주요한 CA들의 인증서를 비교할 수 있는 자료가 있다. 이를 참고한다. 테이블로 만들어놨고 가격도 나와있어http://en.wikipedia.org/wiki/Comparison_of_SSL_certificates_for_web_servers 또 국내의 웹호스팅 업체들이 CA를 대행해서 인증서를 판매하고 있기 때문에 영어나 행정절차가 부담된다면 이들 업체를 이용하면 된다.
(이 위키 사이트도 없어짐, 그냥 뭐하는지 보기)
Comparison_of_SSL_certificates_for_web_servers로 검색해도 Firefox 3? IE 7? 이런거 나오는데
---
저 위키 문서 보면
인증서도 여러가지 종류가 있고 종류별로 얼마나 더 타이트하게 신뢰도를 체크하는가에 따라서 가격이 달라져
우리가 쓸 건 가장 저렴한 가격, 이것만 해도 암호화나 도메인 신뢰성 사용하는데 무리가 없다
더 비싼건 편의 기능 제공, 인증서를 신청한 업체나 조직이 정말로 그 조직인지, 신뢰할 수 있는 조직인지 더 꼼꼼하게 체크할 수 있는 옵션 제공
클라이언트의 자물쇠 부분이 더 화려하다. 더욱더 믿을 만한 곳이다 어쩌구.. 은행이라든지 이런곳은 더 고가의 인증서를 쓴다. 근데 굉장히 고가야
표 보는 법
Certificate authority : 인증 기관 --그 중에 CAcert : 무료인증서를 제공하는 기관
Number of domains included : 한번 구입으로 몇개의 도메인에 대한 인증서를 사용할 수 있는가
Number of subdomains induded : 그 도메인에 대한 몇개의 서브도메인을 지원하는지, unlimited는 제한 없음
CAcert는 모든 인증 기능을 풀로 사용할 수 있지만 뒤에 보면 브라우저에 내장 돼 있는 인증 기관리스트에는 포함돼 있지 않다. 그래서 이런건 개발서버나 우리가 고지하는 등의 사용자들이 불편함을 감수할 수 있는 서비스라면 써볼 수 있어
---
StartCom : 1개 도메인 지원, 서브 도메인도 하나 지원, 제한된 형태의 인증서. 대부분의 서비스에서는 충분히 사용할 수 있는 인증서다. 뒤에 Yes Yes Yes
비용 없이도 인증서를 운영할 수 있다! 이걸로 SSL을 구현할 거야
---
(이 사이트 없어짐, 그냥 뭐하는지 보기)
필자가 선택한 CA는 이스라엘 기업인 StarCom이다. 이 회사는 1년간 무료로 사용할 수 있는 인증서를 제공한다. 인증서 구입에 부담이 있는 개인이나 작은 사업자라면 만족할만한 보안을 제공하는 것으로 알려져있다. 이 회사에서 제공하는 무료 인증서는 아래와 같은 기능을 제공한다.
- 웹서버 인증서 (SSL/TLS)
- Client 와 mail 인증서 (S/MIME) --email에서 사용할 수 있는 인증서
- 128/256-bit 암호화
- US $ 10,000 보상금
- 1년간 유효함
---
도메인을 이 인증기관에 등록하는 절차를 진행할거야
1.로그인 페이지로 이동
2.Express Lane 옵션 선택
여기는 웹페이지 자체가 클라이언트 쪽에 SSL이라는것을 요구하는 웹페이지라서 여기를 들어왔을 때 SSL인증 오류가 나는 경우가 있다. 그냥 재빠르게 클릭하면 된다(StartSSL은 클라이언트 측 인증서를 요구한다. 아직 인증서를 발급받지 않은 상태라면 인증서 오류가 발생할 것이기 때문에 Express Lane 옵션을 빠르게 선택해서 이동한다.)
---
적어 놓은걸 어디다 적어놓자. 모든 절차가 끝나고 이메일이 오는데 처음에 입력 했던 정보를 또 한번 써봐라가 옴. 이거 다르면 허위로 간주해서 등록 거부
4.인증메일이 오는데 그 코드를 입력해준다
5.기다리면(한 두시간 일 수도, 내가 쓴 정보를 사람이 확인 중) 다시 이메일을 준다. 이 메일의 내용은 달라질 수 있어 저번엔 집주소와 오피스인지 집인지 까지 확인해달라고 했었대
7.에서 추가적인 답장이 필요하면 또 메일이 올 것
---
9.저 메일에 키값이 들어있고, 메일의 링크를 클릭하면
넣는 칸이 있고 Continue
---
10.Generate Private Key, 내 프라이빗 키를 만들어준다. 암호화를 얼마나 강하게 할것인가 정하고
11.
12.
무슨말이냐면 방금 그 절차를 통해 내 컴퓨터에, 브라우저에 설치된 클라이언트 쪽에 SSL인증서가 설치가 됐다.
이 인증서와 관련한 정보를 수정하려고 한다면 이 인증서를 갖고 있는 브라우저를 통해서만 자신의 SSL인증서 관련된 정보를 변경하는 이 페이지로 로그인할 수가 있다.
방금 봤던 PrivateKey라고 하는건 내 컴퓨터에 설치되는 Key이고, 나중에 내가 인증서와 관련된 어떤 작업을 하기 위해서 이 페이지에 접속을 할 때 지금 이 단계를 통해서 설치된 인증서를 갖고만 로그인을 할 수가 있다. 따로 로그인 절차를 수행하지 않는다. 저 빨간색 네모는 그 인증서가 잘 설치 됐다는 말.
로그인을 하기 위해 만든 인증서다!!자신의 별도의 파일로 보관해서 다른데 갖고 있어야 한다. 백업해 둬야해
Continue누르면 그 다음 절차
---
13.
14.의 이메일 주소는 어떻게 나오냐면 여러분의 도메인을 등록할 때 자신의 이메일을 같이 등록하게 돼 있다. 그 이메일이나 또는 자신의 도메인@관리자 주소를 붙여서 추정을 하는 것임
저 이메일중에 하나로 메일을 받을 수 있다면 그것은 그 도메인 소유자라는 것을 인증할 수 있다는 것
Continue누르면 startssl에서 메일을 발송하겠지
15.
메일에 있는 코드를 카피
16.
붙여넣기
17.까지 하면 해당 도메인에 대한 인증이 끝나고(startssl에게 그 도메인이 내것이라는 것을 확인해준 것)
18
이제 서버측 private key와 public key를 생성할 것
이 두 키는 나중에 대칭키라고 하는 것을 서버쪽에 전달하기 위한 역할을 하는 것
startssl이 비공개키를 나 대신 만들어주기도 한다
key password를 입력하면 내 private key가 더 안전해지지만, 이걸 설정하게 되면 Apache나 웹서버를 세팅하게 될 때 웹서버를 부팅할 때마다 password를 입력해야하는 문제가 생길 수가 있어
나중에 서버를 클라우드나 이런데 세팅하게 되면 부팅할 때 웹서버가 자동으로 동작하도록 해야하는 경우가 있는데 그런 경우에 이런것들은 장애가 될 수 있어서 잘 판단해야한다
저기보면 keysize 는 2048, Secure Hash Algorithm은 sha1을 선택한걸 따라해도 되지만 암호에 대해 잘 알고 있다면 다른 방식을 선택해도 된다
---
19. 이제 이런 화면이 나타남
18에서 입력한 정보들을 통해서 비공개 키를 생성해준 내용이 저기에 들어가 있다.
메모장에다 복사 붙여넣기 해서 ssl.key라는 파일로 저장하면 된다.
메모장 같은건 괜찮지만, 맥 같은 경우는 text editor라는 프로그램이 있는데 걔는 기본적으로 포매팅이라는게 지정 돼 있다
포맷이 없는 plain text모드로 하셔서 저장을 하셔야 깔끔하게 저기 있는 정보만 저장 된다는 것
---
20.이제 도메인에 실제로 추가
Continue를 누르면
이렇게 생긴 화면이 뜬다
그럼 앞에다가 내가 사용하고 싶은 서브 도메인을 입력하면 된다 (이 상품은 도메인을 하나만 제공해서)두개에 대해서만 startSSL이 보호해주게 된다
와일드 카드 인증서를 구입하면 호스트네임이 붙는 저 앞의 부분을 다른걸로 바꿔도 인증서로 보호받을 수 있다
---
저걸 복사해서 ssl.crt라고 하는 파일로 저장하면 된다.
ssl.crt라고 하는 파일에
클라이언트가 SSL방식으로 서버에 접속했을 때
서버가 클라이언트에게 제공할 인증서의 내용이 들어가 있다(인증서에 대한 정보, 우리가 제출한 공개키..)
이 데이터는 CA, Startcom이 갖고 있는 비밀키로 암호화된 상태로 나타나고 있다)
22.의 Save also the... 의 링크를 우클릭해서 내용을 save as하면 파일이 하나가 또 저장되는데 잘 보관해야 한다.
---
▽
비공개키 : ssl.key
공개키 : ssl.crt
---
정리
이상의 절차를 통해서 얻은 정보는 크게 4가지다. 이 정보들을 이용해서 SSL을 제공하는 방법을 알아보자.
- ssl.key : 서버쪽 비공개키
- ssl.crt : 디지털 인증서 --ROOT CA인 Startcom이 갖고 있는 비밀키로 암호화, 이 안에 서버측 공개키도 들어있다
- ca.pem : ROOT CA 인증서 --바로 위에 Save also the 에 root를 클릭했을 때 다운 받을 수 있는 것
- sub.class1.server.ca.pem : 중계자 인증서 --바로 위에 Save also the 에 intermediate 클릭하면 받을 수 있는 것