HTTPS란 무엇일까?

AWS EC2를 사용하여 웹 사이트를 만들어보았지만,

 

http 프로토콜로 밖에 접속을 못하다 보니, 주의를 요한다는 텍스트가 계속해서 나온다.

 

실은 이 웹 사이트는 보안적으로 취약하다고 볼 수 있는데, 

 

그 이유는 클라이언트와 서버가 계속 정보를 주고 받는 웹 사이트의 경우 제3자가 이에 대한 정보를 볼 수 있기 때문이다.

 

해당 웹 사이트는 민감한 정보를 담고 있지 않은 웹사이트이지만, 내 아이디와 비밀번호를 누군가가 알게 될 수도 있다는 건

 

매우 안 좋은 상황일 것이다.

 

그래서, HTTP에서 secure의 의미가 들어간 HTTPS를 적용해야 한다. 

 

여기서 S의 풀네임은 Over Secure Socket Layer이다.

 

 

그렇다면, HTTPS는 HTTP에 비해 무엇이 다르고 어떻게 안전한 것일까?

HTTPS는 크게 2가지의 특징으로 안전하다고 할 수 있다.

 

 

 

첫 번째, 클라이언트가 서버에 보내는 정보를 다른 누군가가 알 수 없게 한다.

 

예를 들어, 로그인 할 때의 프로세스를 살펴보자.

 

사용자가 서버에 접속을 하면 서버는 갖고 있던 개인키와 공개키 중에서 대중에게 공개 가능한 공개키를 사용자에게 넘겨준다.

 

이제, 사용자가 로그인을 하면 서버에서 받은 공개키로 비밀번호를 암호화해서 서버에게 보낸다.

 

여기서, 누가 이 암호화된 비밀번호를 보았다 하더라도, 갖고 있는 공개키로는 이 암호를 절대 풀 수가 없다.

 

이 암호를 풀 수 있는건 해당 개인키를 갖고 있는 서버에서만 가능하므로, 

 

사용자와 서버간의 데이터 전송에 있어서 매우 안전하다고 볼 수 있다.

 

이러한 시스템을 비대칭키 시스템(공개키로 암호화하고 개인키로만 복호화)이라고 하는데,

 

이 개념은 아래의 인증 기관들이 사이트를 신뢰하는 방법에서도 사용이 되니 잘 기억하고 있어야 한다.

 

 

 

 

두 번째, 사용자가 접속한 사이트가 가짜인지 진짜인지, 신뢰할 수 있는 사이트인지를 판별해준다.

 

예를 들어, 네이버의 가짜 사이트에 접속해서, 로그인을 하면 해당 로그인 정보를 다 빼앗기게 된다.

 

 

그렇다면, 사용자가 접속한 사이트가 네이버인걸 어떻게 증명해야 할까?

 

 

네이버에서 사용자에게 보내는 정보들은 그 일부가 네이버의 개인키로 암호화가 되어 있다.

 

사용자는 그 암호화된 정보들을 공개키로 열어보며 정보를 얻는다.

 

하지만, 가짜 네이버 사이트에서 받은 정보는 해당 공개키로 열면 오류가 발생할 것이다.

 

신뢰할 수 있는 기관에서 사용자에게 네이버의 공개키만 검증해준다면,

 

사용자는 이 기준으로 안전하게 네이버를 이용할 수 있는 것이다.

 

 

 

이제 개발자가 해야 할 일은?

 

그렇다면, 이제 내가 만든 웹사이트가 신뢰할 수 있는 사이트라는 입증(==신뢰할 수 있는 공개키 입증)

 

을 받을 수 있도록 공인 인증 기관의 도움을 받아야 한다.

 

Certificate Authority, 줄여서 CA라고 하는 기관들이 아래와 같이 있다.

 

엄격한 인증과정을 거쳐야 CA를 할 수 있다고 한다.

출처 : 위키백과

 

우리가 사용하는 브라우저들(Chrome, Safari, IE, Firefox, Edge, ...)에게는 이 CA들의 목록이 내장되어 있다.

 

자, 그럼 이 브라우저들에서 네이버에 접속할 때, 어떠한 과정을 거치는 알아보면서 이런 인증기관들을 어떻게 사용하는지 이해해보자.

 

클라이언트(==브라우저)가 네이버에 접속을 하면, 처음엔 네이버 서버를 신뢰하지 못하는 상태가 된다.

 

그래서 이 둘은 먼저 일종의 탐색과정을 거치게 되는데, 이를 HandShake(악수)라고 한다.

 

HandShake

1. 먼저 클라이언트는 어떤 랜덤 데이터를 생성해서, 서버에 보낸다.

2. 이걸 받은 서버는 답변으로 서버측에서 새로 생성한 랜덤 데이터와 서버의 인증서를 실어 보낸다.

3. 1번과 2번의 과정으로 이 둘은 '악수'를 하게 된 것이다.

 

HandShake 과정이 끝나고, 이 클라이언트는 먼저 서버에게 받은 인증서가 진짜인지 확인을 하게 된다.

 

이때, 브라우저에 내장된 CA들의 정보를 통해 확인하는데 이때도 비대칭키 시스템을 사용한다.

 

CA의 인증을 받은 인증서들은 해당 CA의 개인키로 암호화가 되어 있다.

 

'B'라는 CA가 있고, 이 CA가 네이버 서버를 신뢰하고 있다고 하자.

 

서버로 부터 전달 받은 인증서가 진짜라면, 'B'의 공개키로 복호화할 수도 있을 것이다.

 

이 인증서를 공개키로 복호화할 수 있다는건, 그에 대응하는 개인키를 가진 이 'B' 뿐일 것이다.

 

만약, CA리스트 중에 이 인증서가 해당하는 것이 없다면,

 

지금과 같이 이런 표시가 뜨게 되는 것이다.

 

자, 그렇게 성공적으로 복호화된 인증서에는 네이버 서버의 공개키가 포함되어 있다.

 

'그럼 이제 해당 공개키로 클라이언트와 네이버가 비대칭키 방식으로 데이터를 주고 받으면 되겠구나.'

 

라고 생각할 수 있지만, 이제부턴 대칭키 + 비대칭키 방식으로 데이터를 주고 받게 된다.

 

왜냐하면, 계속해서 비대칭키 방식으로 메시지를 암호 및 복호화 하는건, 대칭키 보다 컴퓨터에 부하를 줄 수 있기 때문이다.

 

사이트를 이용할 때 주고 받는 수 많은 데이터를 비대칭키 방식으로 주고 받는건 아무래도 무리가 있다는 것이다.

 

그래서, 이 데이터는 대칭키로 암호화를 한다.

 

'모든 데이터를 대칭키로만 주고 받는다고? 그래도 위험하지 않나...?' 라고 생각할 수 있을 것이다.

 

 

여기서 중요한 한 가지는, 그 대칭키를 공유할 때 비대칭키를 사용한다는 것이다.

 

아까 HandShake 과정에서 전달 받은 무작위의 데이터가 있었다.

 

클라이언트는 내가 만들었던 무작위 데이터와 서버에서 받은 무작위 데이터를 혼합해서 또 하나의 임시 키를 만든다.

 

이 임시 키는 서버의 공개키로 암호화되서 서버로 보내진 다음, 양쪽에서 어떤 일련의 과정을 거친 후,

 

동일한 대칭키가 만들어진다.

 

이제 이 대칭키는 클라이언트와 서버만 갖고 있으니깐, 이후 서로 주고 받는 데이터들을

 

제 3자가 알아볼 걱정이 없게 되는 것이다.

 

 

정리하자면,

 

매번 데이터를 주고 받을 때마다 비대칭키 방식을 이용하면 컴퓨터에 부담을 줄 수 있으니

 

HandShake과정에서 생성된 임의의 데이터로 서로만 볼 수 있는 대칭키를 만들어, 

 

이후 요청과 응답 과정에서 그 정보를 제 3자가 볼 수 없게끔 한 것이다.

 

 

실제 웹 서비스를 만든 입장에서 HTTPS가 어떤 원리로 이루어져 있고, 어떻게 해서 HTTP와 다른지 이해하는건 필수라 생각한다.

 

추후, HTTP나 데이터 요청과 응답 과정에서 문제가 발생했을 때, 그 원리를 알아야 더 쉽고 빠르게 해결을 할 수 있기 때문이다.

 

HTTPS가 완벽한 보안 방법은 아니지만, 현재 모든 사이트에서 이 방식을 채택하는 것보면 아직 더 나은 대체재가 없는 것이 아닐까 생각된다.

 

 

 

 

 

출처 : https://www.youtube.com/watch?v=H6lpFRpyl14&list=LL&index=1