HTTP와 HTTPS - 1편
오늘은 인터넷을 사용해봤다면 한번쯤 접해보았을 HTTP와 HTTPS에 대해서 알아보려고 합니다.
이 둘은 프로토콜로서 우리가 웹 사이트에 접속하기 위해 입력한 URL의 앞쪽에 항상 위치하고 있으며
프로토콜이란 데이터를 주고받는 각 기기가 전송 할 데이터의 교환 방식을 정의하는 규칙을 말합니다.
HTTP (HyperText Transfer Protocol)
먼저 위의 풀네임에서 등장하는 하이퍼텍스트와 비슷한 이름을 가진 하이퍼링크의 차이점에 대해 잠깐 알아보면
하이퍼텍스트는 다른 문서로 바로 이동할 수 있는 문서(하이퍼링크를 가질 수 있는 문서)를 말하며
하이퍼링크는 하이퍼텍스트 내부에서 다른 문서를 가르키고 있는 링크를 말합니다.
위 사진에서 보이는 문서들은 모두 하이퍼링크를 가진 하이퍼텍스트입니다.
HTTP는 주로 HTML과 같은 파일을 주고 받을 때 사용되며 우리가 웹 사이트를 보는 과정은 아래와 같습니다.
- 먼저, 클라이언트(브라우저)가 해당 도메인의 서버에게 HTML, CSS, JS와 같이 사이트를 구성하는데 필요한 파일들을 요청합니다.
- 요청을 받은 서버는 응답과 함께 파일들을 클라이언트에게 보내줍니다.
- 서버의 응답을 받은 브라우저는 해당 파일들을 조합하여 시각화한 결과물을 우리에게 보여줍니다.
그래서 HTTP는 클라이언트의 요청에는 사이트 구성에 필요한 데이터의 형식,
서버의 응답에는 사이트 구성을 위해 전송한 데이터의 형식을 표현하는 역할을 합니다.
HTTPS (HTTP over Secure Socket Layer)
HTTPS는 HTTP에서 보안이 추가된 프로토콜로 뒤의 S는 "Secure", "over TLS"등으로도 사용합니다.
HTTP 프로토콜은 통신 과정에서 데이터에 대한 암호화 과정이 없습니다.
그래서 통신을 주고 받을 때 데이터는 우리가 보고 있는 문자열 형태 그대로 전달되는데
만약 해커가 통신 중간에 데이터를 탈취한다면 사용자의 정보가 그대로 유출될 수 있습니다.
반면 HTTPS는 데이터를 주고 받기 전에 키(Key)라는것을 이용해 데이터의 암호화 및 복호화(암호 해독)과정을 진행한 후 전송합니다.
예를 들어, 사용자가 웹 사이트에 접속하여 자신의 아이디와 비밀번호를 입력한 후 로그인 버튼을 클릭하면
데이터를 전송하기 전 클라이언트에서 전송 할 데이터에 대해 암호화를 진행한 후 서버에게 전송합니다.
암호화된 데이터를 받은 서버는 자신이 가지고 있는 키를 이용해 복호화하여 사용자의 정보를 확인합니다.
이처럼 데이터가 암호화 되어 전송되기 때문에 만약 중간에 해커가 데이터를 탈취하더라도
해커는 키를 가지고있지 않으므로 데이터를 해석할 수 없습니다.
그래서 최근 대부분의 브라우저에서는 사용자의 보안을 위해 HTTP방식을 사용하는 웹 사이트에
접속하게 될 경우 아래와 같은 경고창을 표시하고 있습니다.
만약 내가 접속한 사이트가 HTTPS를 사용하고 있는지 확인하려면 아래 사진과 같이 주소창 왼쪽에 자물쇠표시가 있는지 확인하면 됩니다.
위에서 언급한 암호화와 복호화에 사용되는 키는 대칭키 방식과 비대칭키방식 두 가지로 나누어지는데 이들은 또 어떤 부분이 다른지 알아보겠습니다.
대칭키 방식 (= 비밀키 방식)
대칭키 방식은 이름 그대로 같은 키 두 개를 한 쌍으로 생성하며 이는 암호화와 복호화에 사용됩니다.
그래서 사용자가 서버에 요청하면 서버는 같은 키 2개를 생성하여 한개는 본인이 보관하고
나머지 한개는 클라이언트에게 전달해주게 됩니다.
아무 키나 사용해서 자물쇠를 열 수 없듯이 특정 키로 암호화된 데이터는 반드시 같은 키를 사용해야만 복호화 할 수 있습니다.
대칭키 방식은 알고리즘이 복잡하지 않아 암호화 및 복호화시 속도가 빠르다는 장점이 있습니다.
하지만, 단점도 있는데 첫 번째는 접속자가 증가하면 관리해야할 키의 개수도 증가한다는 점입니다.
각 사용자의 키는 서로 다른 규칙을 가지고 있기 때문에 사용자의 수만큼 관리해야하는 키의 개수가 증가하게 되며 이는 키를 관리하는 서버에게 많은 부담이 됩니다.
두번째 단점은 서버가 클라이언트에게 키를 전달하는 과정에서 키가 탈취 될 수 있다는 점입니다.
서버는 키를 통해 사용자를 구분하기 때문에 만약 해커가 사용자의 키를 탈취해 사용하게 된다면
서버는 현재 연결된 사용자가 실제 사용자인지 해커인지 구분할 수 없습니다.
그래서 이와 같은 단점을 보완하기 위해 비대칭키 방식이 만들어지게 됩니다.
비대칭키 방식(= 공개키 방식)
공개키 방식으로도 불리는 이 방식은 서버가 키를 생성할 때 공개키 한개, 비밀키 한개로
서로 다른 한쌍의 키를 생성하게 됩니다.
서버는 생성한 2개의 키 중 비밀키는 자신이 가지고 있고 공개키는 서버에 접속하고자 하는
모든 클라이언트에게 제공합니다.
여러명의 사용자가 있어도 동일한 공개키를 사용하기 때문에 위에서 말한 여러개의 키를 관리해야하는 불편함을 줄일 수 있습니다.
또한 비대칭키 방식의 특징은 암호화 및 복호화를 진행할 때 각각 한 개의 키만 사용이 가능하다는 점입니다.
예를 들어, 공개키로 암호화 할 경우 비밀키로만 복호화가 가능하고 반대로 비밀키로 암호화했다면 공개키로만 복호화가 가능합니다.
그래서 만약 사용자가 자신의 ID와 PW가 담긴 데이터를 공개키로 암호화해서 서버에 전달하면
해당 데이터는 서버만 가지고 있는 비밀키로만 복호화가 가능합니다.
따라서 해커는 서버를 해킹해서 비밀키를 빼오지 않는 이상 해당 데이터를 복호화 할 수 없습니다.
그래서 노출되면 안되는 데이터는 공개키로 암호화한 후 상대방에게 전달하게 되고
반대로 비밀키로 암호화하는 경우는 데이터의 내용은 노출되어도 상관없지만 데이터를 보낸 자가 누구인지가 중요한 경우입니다.
다만, 이 비대칭키 방식에도 단점이 있는데 대칭키에 비해 알고리즘이 복잡하기 때문에 암호화 및 복호화에 많은 자원과 시간이 소비되며 데이터가 크면 클수록 더 많은 시간이 소요되게 됩니다.
그래서 대부분 이 2가지 방식의 장단점을 이용해 혼합해서 사용합니다.
처음 접속 시에는 비대칭키 방식을 사용해 서로를 검증하고 이후 통신부터는 대칭키 방식을 사용하게 됩니다.
| 대칭키 (= 개인키) | 비대칭키 (= 공개키) | |
|---|---|---|
| 장점 | - 알고리즘이 단순하여 암호화 및 복호화에 필요한 자원과 시간소모가 적다. - 전송 과정에서 탈취되지만 않는다면 안전하다. | -전송 과정에서 탈취되더라도 사용자의 정보가 노출되지 않기 때문에 안전하다. |
| 단점 | - 사용자가 늘어날수록 여러개의 키를 관리해야하는 부담이 있다. - 키 전송 과정에서 탈취에 대한 위험이 있다. | - 알고리즘이 복잡하여 암호화 및 복호화에 많은 자원과 시간이 소모된다. |
위에서 비대칭키 방식은 서버가 생성한 공개키를 클라이언트가 가져와서 사용하는거라고 했었는데
만약 이 공개키가 진짜 서버가 아닌 피싱사이트와 같은 가짜 서버에서 만들어진 공개키라면 어떻게 될까요?
그렇게 된다면 우리의 정보는 바로 해커에게 넘어가게 될 것이기 때문에
우리는 통신하려는 서버가 진짜 서버인지 검증해야할 필요가 있고 이를 도와주는게 바로
디지털 인증서입니다.
디지털 인증서(Digital Certificate)란?
디지털 인증서는 클라이언트와 서버간의 통신을 제 3자가 보증해주는 전자화된 문서입니다.
여기서 제 3자란 CA(Certificate Authority)라고 불리는 공인된 인증서 발급 업체입니다.
CA는 민간기업이지만 아무나 될 수는 없고 엄격한 심사를 거쳐야만 선정될 수 있으며
대표적으로는 DigiCert, GoDaddy, GlobalSign, Comodo와 같은 기업이 있습니다.
구글에서 사용하는 인증서
사이트의 인증서는 주소창에 있는 자물쇠를 눌러 확인할 수 있으며
크롬의 경우 자물쇠를 클릭한 뒤 "인증서가 유효함" 버튼을 누르면 확인할 수 있습니다.
HTTPS 프로토콜을 사용하고자 하는 서버는 반드시 이 인증서를 발급받아야 하며
인증되지 않은 사설 인증서 발급업체도 있지만 그런 업체의 인증서로는 HTTPS프로토콜을 쓴다 한들 마찬가지로 경고창이 띄워집니다.
이렇게 되는 이유는 우리가 사용하는 브라우저의 내부에는 브라우저의 제조사들이 선택한 CA리스트가 포함되어 있습니다.
만약 현재 사이트의 인증서가 이 CA리스트에 없는 업체의 인증서라면 위처럼 경고를 띄우게 됩니다.
그래서 서버는 사설 인증서 발급업체가 아닌 공인된 CA업체에 인증서를 신청하는 것이 좋으며
업체별, 인증서 종류별로 가격이 조금씩 다르게 형성되어있습니다.
다음편에서는 서버가 CA에게 인증서를 발급받는 과정, CA의 종류와 SSL, TLS까지 다뤄볼 예정입니다.
만약 비대칭키의 원리가 잘 와닿지 않으신다면 아래 링크를 통해 공개키와 비밀키가 어떻게 동작하는지
직접 체험해보면 좋을 거 같습니다.
Online RSA Encryption, Decryption And Key Generator Tool | devglan
참조 사이트
What is SSL TLS HTTPS | Hostinger
