프론트엔드Explorer

HTTPS, 대칭키, 공개키, CA에 대해 모른다면 아래 포스팅을 참고해보자. 

https://dolphinsarah.tistory.com/52

SSL은 아래 3가지 액션으로 인해 동작하게 된다. 

• 악수(handshake)
• 데이터 전송
• 세션 종료

악수(handshake)

클라이언트, 서버 간의 통신을 하기 전 실제 통신을 할 수 있는지, 서로 검토하는 단계이다. 

사람이 처음 만나면 악수를 하듯이, 클라이언트와 서버도 비슷하다. 

클라이언트가 서버에 처음 접속하게 되는 시점, 단계를 Client Hello라고 한다. 

또한, 서버는 Client Hello에 대한 응답으로 Server Hello를 하게 된다. 

Client Hello 단계

• 클라이언트에서 랜덤 데이터를 생성한다. 
• 클라이언트에서 사용할 수 있는 암호화 방식들을 서버에 전달한다. 
• 클라이언트에서 사용되는 암호화 방식과 서버에서 가능한 암호화 방식이 다를 수 있기 때문에, 두 군데 모두 사용할 수 있는 암호화 방식에 대해 협상이 필요하다. 

Server Hello 단계

• Client Hello에 대한 응답 과정이다. 
• 클라이언트와 동일하게 랜덤 데이터를 생성하며, 클라이언트에 전달한다. 
• 클라이언트가 전달한 암호화 방식 중에서 서버 쪽에서도 사용할 수 있는 암호화 방식을 선택해서 클라이언트로 전달한다. 채택된 암호화 방식으로 클라이언트-서버 간 통신이 진행된다. 물론 클라이언트에서 보내준 암호화 방식을 서버에서 지원하지 않는다면, 암호화 협상 결렬로 인해 악수는 불발된다. 
• 서버가 발급받은 인증서를 클라이언트로 전달한다. 

Client 인증 단계

• 클라이언트는 서버의 인증서가 CA에 의해서 발급된 것인지를 확인하기 위해 클라이언트에 내장된 CA 리스트를 확인한다. CA 리스트에 인증서가 없다면 사용자에게 경고 메시지를 출력한다. 인증서가 CA에 의해서 발급된 것인지를 확인하기 위해 클라이언트에 내장된 CA의 공개키를 이용해서 인증서를 복호화한다. 복호화에 성공했다면 인증서는 CA의 개인키로 암호화된 문서임이 암시적으로 보증된 것이다. 인증서를 전송한 서버를 믿을 수 있게 된 것이다. 
• 클라이언트는 Server Hello 단계에서 받은 랜덤 데이터와 Client Hello 단계에서 생성한 랜덤 데이터를 조합하여 pre master secret 키를 생성한다. 이 키는 데이터를 주고받을 때 사용하기 위한 암호화 키이며 대칭키 방식으로 사용되어질 키 값이다. 중요한 키임으로 절대 제 3자에게 노출되면 안된다. 그렇기 때문에 이 pre master secret 키 값을 서버에게 전달할 때 서버가 제공한 공개키로 암호화 하여 전송하며, 서버는 자신의 비공개키로 복호화하여 pre master secret 값을 취득한다. 클라이언트가 사용한 공개키는 Server Hello 단계에서 전달받은 인증서 안에 들어있다. 

Server 인증 단계

• 서버는 클라이언트가 전송한 pre master secret 값을 자신의 비공개키로 복호화한다. 이제 서버와 클라이언트 모두 pre master secret 값을 공유하게 되었다. 
• 서버와 클라이언트는 모두 일련의 과정을 거쳐서 pre master secret 값을 master secret 값으로 만든다. 
• master secret은 session key를 생성하는데, 이 session key 값을 이용해서 서버와 클라이언트는 데이터를 대칭키 방식으로 암호화 한 후에 주고받는다. 이렇게 해서 세션키를 클라이언트와 서버가 공유하게 된다. 

악수(handshake) 종료

• 위의 과정으로 클라이언트와 서버는 악수 단계의 종료를 서로에게 공유한다. 

데이터 전송

: 실제로 서버와 클라이언트가 데이터를 주고 받는 과정이다. 상대방에게 데이터를 송신하기 전, 악수 단계에서 발생한 세션 키 값으로 데이터를 대칭키방식으로 암호화한다. 

암호화된 데이터는 상대방으로 송신되며, 상대방도 세션키를 알고 있기 때문에 데이터를 복호화할 수 있다. 

SSL 통신은 공개키 방식, 대칭키 방식의 하이브리드 조합으로 통신한다. 

공개키 방식은 컴퓨터 자원을 꽤 많이 사용함으로 비용이 많이 드며, 또한 대칭키 방식만 사용하게 되면 인터넷 상 대칭키를 서로 주고받아야 하는데, 보안상 매우 위험하다.

그래서 속도는 느리지만 데이터를 안전하게 주고 받을 수 있는 공개키 방식으로 대칭키를 암호화하고, 실제 데이터를 주고 받을 때는 대칭키를 이용해서 데이터를 주고 받는 것이다. 

세션 종료

: 데이터 송수신이 끝나면 SSL 통신이 끝났음으로 서로에게 알려준다. 

이때, 통신에서 사용한 세션키(대칭키)를 폐기한다. 

HTTP에 보안처리(SSL)가 된 버전이 HTTPS이다. (요즘은 HTTPS가 웹의 기본 스펙이라고 봐도 무방함)

HTTPS는 기존 HTTP 레이어에서 SSL 또는 TLS 프로토콜을 얹어 평문 데이터를 암호화하고,  

암호화, 인증, 그리고 무결성 보장을 통해 더 안전히 만들어주는 프로토콜이다. 

SSL과 TLS

SSL(Secure Sockets Layer)은 TLS(Transport Layer Security)의 과거 명칭이라고 봐도 무방하다. 

TLS는 SSL 3.0을 기초로 해서 IETF가 만든 프로토콜이다. 

TLS는 SSL 3.0을 보다 안전하게 하고, 프로토콜의 스펙을 더 정확하게 안정성을 높이는 목적으로 고안하였다. 

SSL이나 TLS를 통해 평문을 암호화하고, 복호화할 때,

대칭키나 공개키 방식을 사용하는데 이에 대해 알아보자. 

대칭키

대칭키 암호화 방식은 집 열쇠와 같다고 생각하면 된다. 

대칭키를 가지고 데이터를 암호화하고, 또 대칭키로 데이터를 복호화한다. 

예를 들어 'abc'라는 키로 데이터를 암호화했다면, 데이터를 복호화하기 위해서는 반드시 'abc' 키가 필요하다. 

즉, 클라이언트와 서버가 대칭키 방식으로 통신을 한다면, 클라이언트도 키를 가지고 있어야 한다. 

그런데 대칭키 방식은 치명적인 단점이 있다. 

암호를 주고 받는 사이에서 대칭키를 전달하는 것이 어렵고, 

만약, 중간에 대칭키가 탈취 또는 유출되면 그 키로 암호화 되었던 데이터들은 모두 유출된다. 

즉, 원거리에서 대칭키를 안전하게 전달하는 것은 매우 어렵다. 

이러한 대칭키의 단점을 극복하고자 나온 방식이 공개키 방식(PKI, Public Key Infrastructure)이다.

공개키(비대칭키)

공개키 방식은 공개키와 개인키(비밀키)라는 2가지의 비대칭키를 가진다. 

만약, A키로 암호화하면 B키로 복호화 가능하며, 반대로 B키로 암호화하면 A키로 복호화가 가능하다. 

A와 B 중 하나는 공개키(public key)가 되고, 나머지 하나는 비공개키(private key)가 된다. 

비공개키는 소유자, 즉, private한 사용자가 가지고 있게 되며, 

공개키는 소유자와 타인에게 공개되는 키이다. 

타인이 공개키를 이용하여 데이터를 암호화해 소유자에게 전달하면, 

소유자는 비공캐기로 복호화하여 그 데이터를 얻을 수 있게 된다. 

이 방식은 안전하게 데이터를 주고받을 수 있게 만들어주지만, 속도가 느리다는 단점이 있다. 

전자서명

비공개키의 소유자는 비공개키를 이용해서 정보를 암호화 한 후에 공개키와 함께 암호화된 정보를 전송한다. 

정보와 공개키를 획득한 사람은, 공개키를 이용해 암호화된 정보를 복호화한다. 

이 과정에서 공개키가 유출된다면 의도하지 않은 공격자에 의해 데이터가 복호화될 위험이 있다. 

이런 위험에도 불구하고 비공개키를 이용해 암호화를 하는 이유가 뭘까? 

비공개키는 데이터를 보호하는 것이 목적이 아니다. 

암호화된 데이터를 공개키를 가지고 복호화할 수 있다는 것은 그 데이터가 공개키와 쌍을 이루는 비공개키에 의해서 암호화되었다는 것을 의미한다. 

즉, 공개키가 데이터를 제공한 사람의 신원을 보장해주는 것이다. 이러한 것을 전자서명이라고 부른다.

SSL 인증서와 CA(Certificate Authority)

SSL을 적용하기 위해서는 인증서가 필요하다. 

SSL 인증서는 아래의 2가지를 제공한다. 

• 클라이언트가 접속한 서버가 신뢰 있는 서버임을 증명(인증서 발급 CA, 도메인 등)한다. 즉, 클라이언트가 접속한 서버가 클라이언트가 목적한 서버가 맞는지 확인한다. 
• SSL 통신에 사용될 공개키를 클라이언트에 제공(서버 공개키)한다. 서버와 클라이언트가 통신할 때 사용될 공개키와 공개키 암호화 방법들의 정보가 있다. 

CA는 이 SSL 인증서를 발급해주는 기업이다. 

인증서가 보안에 관련된 것인만큼 CA는 신뢰할 수 있는 기업에서만 가능하다. 

SSL 인증서 및 내용은 CA에 의해서 암호화된다. 이때 CA는 자신의 비공개키로 서버가 제출한 인증서를 암호화한다. 

CA의 비공개키는 절대로 유출되어서는 안되며, 실제로 디지노타라는 회사에서 CA의 비공개키가 유출된 사례가 있어 CA 자체가 파산된 경우도 있다고 한다. 

브라우저와 CA

브라우저는 내부적으로 CA의 리스트를 미리 알고 있다. 

즉, 브라우저 소스 안에 CA 리스트가 존재한다는 말이다. 

CA 리스트 뿐만 아니라, 각 CA의 공개키도 이미 브라우저 안에 내장되어 있다. 

브라우저가 서버에 접속할 때, 서버는 클라이언트에게 인증서를 제공한다. 

브라우저는 서버에서 받은 인증서가 자신이 가지고 있는 CA 리스트에 있나 확인을 한다. 

비교 후 정상적인 인증서이면, 해당 CA의 공개키(브라우저 안에 있는)를 이용하여, 인증서를 복호화한다. 

복호화가 됐다면, 그 인증서는 CA의 비공개키로 암호화된 것을 의미한다.

즉, 해당 CA에 의해 정상적으로 발급된 인증서라는 의미가 되며, 그것은 클라이언트가 접속한 서버에서 제공한 인증서가 해당 CA에 의해 정상적으로 발급됐다는 의미이다. 

=> 클라이언트가 접속한 서버에서 받은 인증서가 CA에서 정상적으로 발급된 인증서이다. 

다음 포스팅에서는 HTTPS의 동작 원리에 대해 알아보도록 하자. 

https://dolphinsarah.tistory.com/53