개요
- HTTP 프로토콜의 역할과 보안 이슈에 대해 학습한다.
- HTTPS 프로토콜이 어떤 원리로 보안을 강화하는지 학습한다.
- SSL (Secure Sockets Layer) 프로토콜이 어떤 역할을 하는지 학습한다.
- 인증서와 인증 기관에 대해 학습한다.
HTTP와 HTTPS
본 포스팅에서는 HTTPS의 도입 이유 및 필요성을 설명하기 위해 HTTP에 대한 간략한 이야기만 제공한다. HTTP에 대해 포스팅도 언젠가는 하겠지..?!
HTTP 정의
HTTP(HyperText Transfer Protocol)는 인터넷에서 데이터를 주고 받을 수 있도록하는 응용계층의 프로토콜이다. 클라이언트-서버 간의 통신 구조를 만드는데, 이는 클라이언트가 서버에 요청을 보내면 서버가 요청에 대한 결과를 만들어서 응답하는 것을 의미한다. 그리고 이와 관련된 규칙을 프로토콜로 정의한것이 바로 HTTP이다.
메시지 (Message)
클라이언트가 서버로 요청을 보내거나, 서버가 클라이언트로 응답을 보낸다고 했는데, 그 매개체는 무엇일까? 바로 메시지다.
클라이언트가 서버로 전송하는 메시지를 요청 메시지 (Request Message)라고 부르며, 서버에서 응답으로 전송하는 메시지를 응답 메시지 (Response Message)라고 부른다.
응답 메시지의 예시를 가져왔다. 요청 메시지의 경우도 비슷한 모양새를 가진다. 여기서 말하고 싶은 것은, HTTP 메시지의 경우 몇 줄의 텍스트로 구성된다는 것이다.
HTTP의 문제점
위에서 했던 말을 정리하면 다음과 같다.
클라이언트와 서버는 텍스트로 이루어진 메시지를 통해 소통한다.
단순해 보이지만, 네트워크는 생각보다 많이 복잡하다. 그리고 그에 따른 보안 문제가 분명 존재한다. 예를 들어, 두 엔드포인트간 데이터가 전달되는 과정에서 수많은 라우터를 거치게 되는데, 혹시라도 나쁜 마음을 가진 해커가 경로 어딘가에서 메시지를 몰래 본다면 어떻게 될까?
메시지는 '몇 줄의 텍스트'로 이루어져있다. 심지어 사람이 이해하기 쉽게 작성되어있다. 즉 누구나 읽을 수 있고 의미를 해석할 수 있다. 메시지에 주민등록번호와 같은 민감한 정보가 포함된다면 외부로부터의 탈취에 대응하기 힘들다.
HTTPS의 도입
HTTPS는 HTTP over Secure Sockets Layer의 약어다.
기존 HTTP이 보안에 취약하다는 것을 개선하고자 SSL(Secure Sockets Layer) 기술을 추가한 것이다. SSL은 암호화 기반의 인터넷 보안 프로토콜이다.
SSL
SSL이 제공하는 기능은 다양하다. 웹에서 전송되는 데이터를 암호화하고, 신뢰할 수 있는 사이트임을 증명하는 '인증서'를 검증하기도 한다. 기반 기술은 SSL에서의 암호화 방식이므로 우선 이를 이해할 수 있어야한다.
SSL - 암호화
암호화와 복호화
기존 데이터를 암호화된 데이터로 만드는 과정을 암호화라고 한다. 반대로 암호화된 데이터를 원본 데이터로 되돌리는 것을 복호화라고 한다.
암호를 만들 때, 특별한 규칙 없이 만들면 나중에 해석이 불가능하다. 그래서 키라고 불리는 것이 필요하다. 키를 이용해 고유의 암호를 만들 수 있으며, 만들어진 암호를 복호화 할 수도 있다. 키는 문자열을 일반적으로 사용하지만 다른 자료형으로도 사용 가능하다.
SSL의 암호화를 이해하기 위해 필요한 암호화 방식 몇가지를 소개한다.
대칭키 암호화
키워드 : 대칭키
데이터를 암호화하는 키와 복호화하는 키를 동일하게 가져가는 암호화 방식이다. 이러한 동일한 키를 대칭키라고 부른다.
// 이미지
예를 들어, 클라이언트가 대칭키를 이용해 민감한 데이터를 암호화했다고 가정한다. 서버가 클라이언트에서 제공한 대칭키를 알고 있다면, 해당 키를 이용해 데이터를 복호화해 사용하면 된다.
서버와 클라이언트는 사전에 대칭키를 공유해야한다. 대칭키를 공유하는 방식에서 문제가 발생하는데, 중간에 해커가 대칭키를 낚아채간다면 데이터를 누구나 복호화해서 열람할 수 있는 보안 문제가 발생한다. 따라서, 해당 대칭키를 안전하게 전달하는 것이 중요하다.
비대칭키 암호화
키워드 : 공개키 / 개인키
데이터를 암호화하는 키와 복호화하는 키를 다르게 사용하는 암호화 방식이다. 공개키와 개인키를 이용해 데이터의 암호화를 관리한다.
공개키를 이용해 암호화된 데이터는 개인키로 복호화를 할 수 있다.
반대로, 개인키를 이용해 암호화된 데이터는 공개키로 복호화를 할 수 있다.
// 이미지
서버와 클라이언트는 각각 자신만의 공개키와 개인키를 가지고 있다. 어감 그대로 공개키는 누구에게나 공개가 가능한 키다. 탈취되어도 큰 문제가 되지는 않는다. 하지만, 개인키는 어딘가에 노출되면 절대 안된다. 공개키로 암호화된 데이터는 개인키를 이용해서만 복호화 할 수 있기 때문에, 개인키가 노출되는 경우 큰 보안사고가 발생할 수 있다. 그냥 자신만이 잘 간직하고 있으면 된다.
SSL이 채택한 암호화 방식
대칭키를 이용해 암호화를 하면, 암호화와 복호화가 간편하다는 장점이 있다. 대신 대칭키를 공유하는 과정에서 대칭키가 노출될 수 있기 때문에, 보안적으로 취약하다는 단점이 있다.
비대칭키를 이용한 암호화 방식은 개인키만 잘 숨겨두면 보안적으로 안전하다는 장점이 있다. 하지만, 복잡한 수학적 원리로 암호화가 진행되기 때문에 CPU의 리소스를 많이 잡아먹는다는 문제가 있다.
그래서 SSL은 이 둘의 단점을 보완하고 장점을 살리기 위해 그냥 둘 다 사용한다. 즉, 보안과 성능 이슈 모두를 고려한 방식이다.
어떻게 이게 가능할까?
대칭키는 노출되면 위험하다. 하지만, 외부에 노출되지 않은 상태로 안전하게 공유된다면 비대칭키 암호화 방식보다 더 빠르게 암호화 및 복호화를 할 수 있다.
사람들은 참 똑똑하다. 대칭키를 비대칭키 암호화 방식을 이용해 공유하면, 클라이언트-서버간 대칭키를 안전하게 공유할 수 있게된다.
// 이미지
- 송신자는 수신자의 공개키를 이용해 대칭키를 암호화해서 넘긴다.
- '암호화된 대칭키'가 수신자쪽으로 안전하게 전달된다.
- 수신자는 전달받은 '암호화된 대칭키'를 자신의 개인키로 복호화한다.
- 수신자는 원래 대칭키를 잘 가지고있으면 된다.
그 이후로는, 해당 대칭키를 이용해 데이터를 암호화해서 보내고, 받은 데이터를 복호화해서 사용하면 된다.
정리하면 다음과 같다.
비대칭키 암호화 방식을 이용해 대칭키를 공유하고,
대칭키 암호화 방식을 이용해 실제 데이터를 송·수신하는 방식을 이용한다.
SSL - 신뢰할 수 있는 사이트임을 검증하기
SSL에서 사용하는 암호화 방식을 이용하면, 데이터를 중간에 탈취당해도 해커가 어떤 데이터인지 알아내기 힘들기 때문에 상당히 안전하다는 것을 언급했다.
하지만, 애초에 내 소중한 개인정보를 '악의적인 목적을 가진 사이트'에 전송해버리는 경우가 생길 수 있다. (사칭 페이지나, 스팸 페이지 등 정말 다양한 케이스가 있다.) 이런 경우, 아무리 암호화가 된다한들 개인정보를 보호할 수 없게된다.
SSL은 암호화 방식에서 더 나아가서, 신뢰할 수 있는 사이트임을 인증서를 이용해 검증하는 방식까지 지원한다. 이를 통해, 사용자는 보다 더 안전하게 웹을 탐험할 수 있다.
CA (Certificate Authority)
CA는 인증서를 발급하고 관리하는 기관이다. 신뢰할 수 있는 사이트임을 검증하는 책임이 있다. CA는 자신만의 공개키와 개인키를 가지고 있다. 당연히 CA의 개인키가 노출되면 모든 '인증서'의 보안에 문제가 생기게된다.
보안을 조금 더 강화하기 위해, CA는 2계층 이상의 연쇄적인 구조를 가지고 있다.
- Root CA (최상위 기관)
- Intermediate CA (중간 기관)
하위 CA가 상위 CA에게 인증서를 요청하고, 또 상위 CA는 더 상위 CA에게 인증서를 요청하는 방식이다. 이를 인증서 체인이라고 한다.
인증서
서버는 자신이 신뢰할 수 있는 안전한 서버임을 모두에게 알리고 싶어한다. 이를 증명하는 문서가 필요한데, 이 때 필요한 것이 인증서다. 흔히 SSL 인증서라고 부르며, CA로부터 발급 받을 수 있다.
서버가 인증서를 발급받는 과정을 설명하면서, 인증서가 어떻게 구성되어 있는지를 설명하겠다.
- 우선, 서버가 CA에게 인증서 발급을 요청하기 위해서 자신의
도메인 주소와공개키를 넘겨줘야한다. - CA는 서버의 공개키를 서명 알고리즘을 이용해 해시하는데, 이를
지문 (Fingerprint)이라고 부른다. - 이후, 만들어진 지문을 CA의 개인키를 이용해 암호화한다. 이를
서명 (Signature)이라고 한다.
이를 통해, 인증서에 어떤 정보가 있는지 생각을 할 수 있다.
- 지문과 서명
- 서명 알고리즘 (지문을 다시 공개키로 만들어야 하니깐)
- 인증서 발급 기관
- 서버 도메인
신뢰할 수 있는 사이트임을 클라이언트가 인식하는 과정
브라우저는 이미 검증된 CA와 CA의 공개키를 알고있다. 이를 전제로 해야한다.
SSL 인증서를 가지고 있는 서버에 접속했을 때, 해당 SSL 인증서가 올바른 것인지, 위조 된 것인지 알 수 있는 방법을 소개한다.
핵심은 인증서의 서명을 복호화한 값과 지문이 일치하는지를 파악하는 것이다.
클라이언트가 서버에 접속하면, 서버는 클라이언트에게 자신의 인증서를 넘겨준다. 인증서에는 해당 인증서를 발급해준 CA 정보가 존재하는데, CA 리스트를 확인해 해당 CA의 공개키를 획득 후 인증서의 서명을 복호화한다. 서명을 복호화 한 값이랑 서버의 공개키를 해시한 값이 일치한다면 인증서가 위조되지 않았음을 나타내는 것이다.
이후에는 획득한 서버의 공개키를 이용해, 대칭키를 암호화하고 처음에 설명했던 보안 통신을 진행하는 것이다.
생각해보기
GET 요청과 POST 요청의 보안
예전에 모 스타트업 면접에서 'GET과 POST의 차이에 대해 설명'해달라는 질문을 받은적이 있었다.
설명 중 GET 방식은 url에 쿼리 파라미터가 그대로 노출되므로 보안에 취약하고, POST 방식은 message body에 숨겨놓기 때문에 보안에 조금 더 유리하다고 설명했다.
그 때, 면접관분이 어쨌든 Network 탭으로 확인하면 GET이나 POST나 관련 데이터를 확인할 수 있는데 왜 POST가 보안에 더 유리한거죠? 라는 질문을 했었는데.. 잘 모르겠다하고 넘어갔던 기억이 있다.
그래서 그냥 GET이나 POST나 보안이랑은 큰 차이가 없나보다~ 하고 말았었는데, 이번에 암호화 방식에 대해 공부하다보니 생각을 조금 달리할 수 있었다.
SSL 방식을 이용한 HTTPS 통신 과정에서 Message가 전체적으로 암호화되기 때문에, 중간에 해당 데이터를 탈취당하더라도 해커는 '암호화된 Message'밖에 못본다. 암호화된 데이터는 클라이언트 사이드에서 복호화를 하며, 데이터를 전송하는 경우에도 암호화된 데이터를 보내기 때문에 GET 방식보다 보안에 안전하다는 판단이 가능한 것 같다.
참고자료
