문제인식

웹 사이트를 배포할 일이 생겼는데, HTTPS로 배포해야 했다.
기존에 HTTPS와 SSL 개념에 대해 잘 몰랐기 때문에 한번 정리가 필요했다.

해결방법

대칭키와 공개키

어떤 내용을 암호화하고 다시 복구하는 복호화를 하려면 크게 두가지 방식이 있다.

1. 대칭키방식
2. 공개키방식

대칭키

대칭키는 일반적으로 생각되는 암호개념이다.
어떤 내용을 암호화할때 사용하는 키와 복호화할때 사용하는 키가 대칭적으로 같은것이다.
예를 들면 도어락을 생각하면된다.
도어락 비밀번호를 설정할때와 도어락을 열때 사용하는 비밀번호가 같으므로 도어락은 대칭키를 사용하는 것이다.
굉장히 직관적이지만 대칭키는 사용하는 사람이 한정적일때만 유용한것같다.
왜냐하면 사용하는 사람이 무한정 많아지면 그 사람들 모두가 같은 암호를 사용하게되는것이고,
그러면 모두가 알고있기 때문에 암호로서의 유용성이 없어지기 때문이다.
막말로 도어락을 열면 안되는 도둑인데, 옆에서 엿보고 눌러서 들어올수도 있기 때문이다.

공개키

공개키는 암호화하는 키와 복호화하는 키가 서로 나뉘어져 있는 방식이다.
하나의 키로 암호화를 했다면 다른 하나의 키로 복호화를 할 수 있다.
예를 들면 택배상자를 생각하면된다.
꽁꽁싸맬땐 특수제작된 테이프를 사용하고, 뜯어볼땐 특수제작된 전용 커터칼을 사용하는것이다.
여기서 테이프를 비밀키라고하고, 칼을 공개키라고 한다.
만약 악의적인 의도를 갖고있는 사람이 특수제작된 전용 커터 칼을 갖고있으며, 다른 사람이 열어봤을때 폭발하도록 하기위해서 택배상자를 재봉합해서 원본인것처럼 속이고 뿌려버린다고 해도,
특수제작된 테이프로 봉합된게 아니기 때문에, 받아본 사람들은 이게 원본이 아닌 이상한 택배 상자라는 것을 알 수 있다.

전자서명, CA, SSL

전자서명

그럼 사람들이 테이프로 봉합된 택배상자를 받았을때, "아 이거 누가 중간에 가로채서 이상한장난을 친 택배가 아니라 진짜구나!"하고 알수있는 방법은 무엇일까?
족발보쌈집에서 배달받을때 비닐로 포장된것에 전용으로 작은 플라스틱칼을 보내주듯이, 특수 봉합된 택배 상자에 특수 제작된 전용 칼을 붙여서 보내주면, 받아본 사람은 이것을 뜯어서 제대로 열린다면 보낸 사람이 만든 택배상자를 중간에 누가 뜯어서 재봉합하지 않고 제대로 보냈구나 하는 것을 자동적으로 알수 있다.
이것을 전자서명이라고 한다.
다시말해 공개키로 컨텐츠를 볼수있다면, 중간에 누군가 장난질을 안했다는것을 확실히 알 수 있다는 것이다.

CA

근데 다시한번 생각해보자.
그럼 중간에 택배를 뜯어서 폭탄을 넣고 봉합해서 보내는 사람이, 본인만의 특수 테이프로 택배 상자를 재봉합하고, 새로운 특수칼을 붙여서 보내게 되면 받는 사람은 어떻게 생각할까?
칼로 상자가 뜯어지긴할테니 아무 의심없이 상자를 열어보게 될테고 그럼 폭발할 것이다.
그럼 전자서명이 무슨의미가 있을까..
이를 해결하기 위해 도입된게 CA이다.
CA는 공인된 제 3자, 관공서라고 생각하면되는데, 특수 제작된 칼을 직접 갖고있으면서 사람들이 필요하다고 할때 직접 주는것이다.
그럼 사용자는 택배상자에 붙어있는 키를 사용하는것이 아니라 CA한테 인증받은 칼을 받아서 쓰면된다.
그럼 택배 보내는 사람이 택배를 보내고, 받는 사람이 받았을때, CA한테 받은 칼로 안뜯어지면, 중간에 누가 장난질을했다는 것을 확실하게 알 수 있다.
그리고 CA한테 칼을 받을때는 전자서명을 또 이용한다.
택배상자를 열 특수 제작칼을 CA한테 전자서명으로 한번 더 묶어서 받는것이다.
왜냐하면 누가 또 한번 더 머리를 써서 CA인척 하고 칼을 넣어서 보낼수도 있기 때문이다.

SSL

SSL은 택배를 보내는 사람, 받는 사람, CA가 할일을 정해놓은 표준 프로토콜이라고 생각하면된다.
CA에서의 예는 보내는 사람, 받는 사람이 공개키 방식을 사용하고, 받는 사람과 CA도 공개키를 사용하는것으로 예를 들었는데,
SSL에서는 보내는 사람, 받는 사람 끼리는 대칭키 방식을 사용하고, 받는 사람과 CA사이에만 공개키를 사용한다.
전부 공개키를 사용하면 더 안전할텐데 왜 보내는 사람과 받는 사람끼리는 대칭키를 사용할까?
왜냐하면 공개키방식을 이용할때 보낼때마다 암호화를 하면 엄청 느려지기 때문이다.

그렇다면 최종 방법은?

1. 클라이언트가 서버를 건드린다.
   이때 클라이언트는 아무 값이나 써서 보내면서 자기가 암호화 할 수 있는 방법들을 나열한것도 써서 보낸다.

2. 서버는 응답을 해준다.
   이때 서버도 아무 값이나 써서 보내면서 클라이언트가 보낸 방법중에 서버도 가능한 방법중 하나를 선택해서 써서 보낸다. 그리고 CA가 준 인증서도 같이 보내준다.

3. 클라이언트는 서버가 준 인증서를 CA의 공개키를 이용해서 뜯어본다. 모든 웹브라우저는 CA의 공개키를 이미 갖고있기때문에 제대로 열리는지 바로 볼 수 있다. 만약에 서버가 준 인증서가 CA가 만든 인증서가 아니면 브라우저는 이거 CA것이 아니라면서 시뻘겋게 경고를 보여준다.
   만약에 CA의 공개키로 인증서가 제대로 열렸다면, 일단 서버가 믿을만한 곳이라는것을 알 수 있다.

4. 클라이언트가 클라이언트에서 만들었던 아무값이랑 서버에서 만들어준 아무값을 조합해서 대칭키 방식으로 pre master secret 값을 만든다.

5. 클라이언트는 만들어놓은 pre master secret값을 서버가 준 공개키를 이용해서 암호화해서 보낸다. 그럼 서버는 이것을 비밀키로 열어볼 수 있다.

6. 서버는 클라이언트가 준 pre master secret값을 열어본다.

7. 클라이언트와 서버는 pre master secret값을 master secret값으로 바꾼다.

8. 그리고 master secret값으로 한번 더 session key를 만든다.

9. session key를 이용해서 대칭키 방식으로 암호화하고 주고 이제 클라이언트와 서버는 실제로 값을 주고 받는다.

다시 한번 정리하면, 서버와 클라이언트는 대칭키 방식으로 암호화해서 통신하는게 가장 편하다.
근데, 특정 대칭키로 고정해버리면 언젠가는 대칭키가 유출 될 수 있다.
그래서 그때그때 대칭키를 만들어서 쓰면 더 안전할 것이다.
그러면 대칭키를 클라이언트와 서버가 서로 알고 있어야 하는데, 이걸 전해주는게 또 위험하다.
그래서 클라이언트가 일단 서버를 믿도록 하기위해서 CA를 이용하고,
그 다음에 클라이언트와 서버 둘이서만 짜고 대칭키를 그때 그때 만드는것이다.