반응형

1. HTTPS와 HTTP

- HTTP : Hypertext Transfer Protocol로 즉 HyperText인 html을 전송하기 위한 통신규약을 의미한다.

- 마지막에 S를 붙인다면 Secure라는 뜻으로 보안이 강화된 통신규약을 의미한다.

- HTTP는 암호화가 되어있지 않은 방법으로 서버에 데이터를 전송하기 때문에 서버와 클라이언트가 서로 주고받는 메시지를 알아내기가 쉽다.

- 그러므로 로그인을 위해서 서버로 비밀번호나 계좌번호 등 중요한 데이터를 서버로 전송할 경우에는 HTTPS 프로토콜을 사용하여 통신하는 것이 중요하다.


2. HTTPS와 SSL

- HTTPS는 SSL 프로토콜을 기반으로 돌아가는 프로토콜 중 하나다.


3. SSL과 TLS

- SSL과 TLS는 같은 뜻으로 말하며 TLS1.0은 SSL3.0을 계승한다. 

- 하지만, TLS라는 이름보단 SSL이라는 이름으로 더 많이 사용되고 있다.


4. SSL이란 무엇일까?

- SSL 인증서란 클라이언트와 서버간의 통신을 제 3자가 보증을 해주는 문서이다.

- 클라이언트가 서버에 접속한 직후에 서버는 클라이언트에게 이 인증서를 전달한다. 그러면 클라이언트는 이 인증서를 보고 신뢰할 수 있는 사람인지 확인을 한 다음에 데이터를 보내는 등 다음 절차를 수행하게 된다.


* SSL를 사용하면 좋은 점

(1) 전달되는 내용이 다른 사람에게 노출되는 것을 막을 수 있다.

(2) 클라이언트가 접속하려는 서버가 신뢰할 수 있는 서버 인지 알 수 있다.

(3) 전달되는 내용이 악의적으로 변경되는 것을 막을 수 있다.


5. SSL에서 사용하는 암호화의 종류

(1) 대칭키

(2) 공개키


5-1. 대칭키

암호를 만드는 행위인 암호화를 할 때 사용하는 일종의 비밀번호를 키(key)라고 한다. 이 키에 따라서 암호화된 결과가 달라지기 때문에 키를 모른다면 암호를 푸는 행위인 복호화도 할 수 없다. 이 중, 대칭키 방식은 동일한 키로 암호화와 복호화를 할 수 있는 기법을 말한다. (Ex. 암호화를 할 때 1234라는 값을 사용했다면, 복호화를 할 때도 1234를 입력해야 복호화가 완료되는 방식이다.)


그러나, 대칭키의 단점이 있다.

암호를 주고 받는 사람들 사이에서 이 키(key)로 암호화하라고 사용자에게 전달하는 것이 어렵다는 점이다. 왜냐하면, 중간에 대칭키가 유출된다면 키를 획득한 공격자는 암호의 내용을 복호화하여 무슨 데이터를 전달하려고 했는지 알 수 있기 때문에 HTTPS를 쓰는 이유가 없어진다. 그래서 나온 방식이 바로 공개키 기법이다.


5-2. 공개키

공개키 방식은 대칭키 방식과 다르게 두 개의 키를 가지고 시작한다. 두 개의 키 중 하나를 비공개키(private key, 개인키/비밀키)라고 부르고 나머지 키를 공개키(public key)라고 말한다. 비공개키는 자신만이 가지고 있고, 공개키는 타인에게 제공한다. 그럼 내가 발행한 공개키를 받은 타인은 공개키를 이용하여 정보를 암호화하고, 암호화된 정보를 비공개키를 가지고 있는 나에게 다시 전달하면 나는 그 데정보를 복호화하여 확인할 수 있다. 


Ex. 클라이언트가 받은 키(key)를 가지고 1234(정보)를 암호화하여 서버에게 !@#$라는 text를 전달 → 서버는 클라이언트가 보낸 !@#$라는 단어를 비공개키로 복호화하여서 1234라는 것을 확인!

여기까지가 공개키의 기본 통신 방법이다.


이제 이 공개키 기법을 응용해보자. 

아깐 공개키를 가진 사람이 암호화해서 전달했으나, 이번엔 비밀키를 가진 사람이 비밀키로 암호화해서 공개키와 함께 암호화된 정보(!@#$)를 전송한다.


정보와 공개키를 획득한 사람은 공개키를 이용하여서 암호화된 정보를 복호화한다. 이 과정에서 공개키가 유출된다면 안되겠지만, 데이터를 보호하려는 목적이 아니고 서로의 신원을 확인하기 위한 방식이므로 유출되어도 상관이 없다. 그러므로 이때, 암호화된 데이터를 공개키로 복호화 할 수 있다는 것은 해당 데이터가 공개키와 쌍을 이루는 비공개키에 의해서 암호화 되었다는 것을 의미한다. 


즉, 공개키가 데이터를 제공한 사람의 신원을 보장해주었다는 것이다.

이것을 우리는 '전자서명'이라고 부른다. 




6. SSL 통신 주고 받는 과정

즉, 위에서 말한 것과 같이 상대방의 공개키를 획득하여 암호화해서 상대방에게 암화된 정보를 제공하고 신원을 확인하는 것이 중요하다. 이러한 절차를 SSL 악수 과정(SSL Handshake)이라고 한다.


<실제 통신 과정>

1단계. Client Hello : 클라이언트가 브라우저나 다른 TCP 통신을 통해서 서버에게 접속한다. 

- 이때 클라이언트는 랜덤한 데이터를 생성하여 서버에게 전송한다. 

- 또 클라이언트가 SSL 통신을 하기 위해 현재 지원가능한 암호화 방식을 서버에게 전덜한다. (자신의 능력을 서버에게 말해주기)


2단계. Server Hello : Client Hello에 대한 응답으로 서버에서 Server Hello를 한다.

- 이번엔 서버에서 생성한 랜덤한 데이터를 클라이언트에게 전송한다.

- 또 이번에는 클라이언트가 지원가능한 암호화 방식에 맞춰 현재 서버에서 제공할 수 있는 가장 안전한 암호화 수단 방식을 클라이언트로 전달한다.

- 또한, 서버가 클라이언트에게 인증서를 전달한다. 


3단계. 클라이언튼 서버가 보내준 인증서가 어떤 CA에 의해서 발급된 것인지 확인하기 위해서 클라이언트에 내장되어있는 CA리스트를 확인한다.

CA리스트에 없는 인증서라면 사용자에게 경고의 메시지를 띄운다.

이때, 인증서가 어떠한 CA에 의해서 발급된 것인지 확인하기 위해서 클라이언트에 내장된 CA의 공개키를 이용하여서 복호화를 한다.

복호화를 정상적으로 성공했다면, 해당 인증서는 CA의 개인키로 암호화 한 문서임이 암시적으로 보증되었고 인증서를 통해서 서버를 믿게 된다. 


클라이언트는 1단계를 통해서 받은 서버의 랜덤 데이터와 클라이언트가 생성한 랜덤 데이터를 조합하여서 pre master secret라는 키를 생성한다.

이 키는 뒤에 살펴볼 세션 단계에서 데이터를 주고 받을 때 사용된다.

이 pre mster secret 키는 3자에게 노출되어선 절대안되는 키다.


이때, pre master secret 키를 다시 서버로 전송을 하는데, 이때 공개키 방식을 이용하여 또 전달한다.


4단계. 서버는 클라이언트가 전송한 pre master secret 값을 자신의 비공개키로 복호화를 한다.

이로서 서버와 클라이언트 모두 pre mater secret 값을 공유하게 되었고, 서버와 클라이언트는 일련의 과정을 거쳐 pre matser secret 값을 master secret 값으로 만든다. 

master secret은 session key를 생성하는데, 이 session key를 이용하여서 대칭키 방식으로 암호화하여 주고 받는다. 



참고 문서


+ Recent posts