[인증/보안] 기초 Chapter - HTTPS

윤후·2022년 3월 24일
0

Section 3

목록 보기
29/41

HTTP 프로토콜 내용을 암호화하여 보안성을 추가한 것이다.

HTTPS


기존의 HTTP요청은 중간에 누군가가 요청을 들여다 본다면 그 내용을 그대로 볼 수 있었다. 그렇게 되면 중요한 개인정보가 쉽게 노출될 수 있었다.

하지만 HTTPS는 통신내용을 한번 암호화 하기 때문에 개인정보, 중요한 정보가 유출 되었더라도 해당 키가 없으면 어떤 내용인지 확인할 수 없다.

HTTPS의 특징


  • 인증서 : 데이터를 제공한 서버가 정말로 데이터를 보내준 서버인지 인증/확인 하는 용도이다. 인증서의 내용에 서버의 도메인 관련 정보가 있어서 데이터 제공자의 인증을 용이하게 한다.
    • 데이터 제공자 신원 보장

    • 도메인 종속

      요청을 받는다면 서버은 인증서와 함께 응답을 전송한다. 응답을 받은 client는 인증서에 작성된 도메인과 응답 객체에 작성된 도메인을 비교한다. 만약에 응답에서 확인한 도메인과 인증서에 작성된 도메인이 같다면, 정말로 데이터를 제공해준 서버가 확실하다는 것을 인지하게 된다.

      만약, 중간에 해커가 요청을 탈취하여 서버인척, 클라이언트인척 정보를 탈취하는 제 3자 공격이 발생하면, 응답에서 확인한 도메인과 인증서에 작성된 도메인이 같지 않아 정말로 데이터를 제공한 서버가 확실하다는 것을 보장할 수 없게 된다. 그렇기 때문에, 클라이언트에서 서버제공자가 아닌 전혀 다른 데이터 제공자임을 알 수 있게 된다.

  • CA (Certificate Authority) : 인증서를 발급하는 공인된 기관이다. 위에서 말한 인증서를 발행해주는 기관이며, 각 브라우져는 신뢰하는 CA의 정보를 가지고 있다. 그래서 각 브라우져는 인증서의 차이가 있게된다.

  • 비대칭키 암호화 : HTTPS는 전혀 다른 키 한쌍으로 데이터를 암호화 및 복호화를 할 수 있다. 다만 어느 하나의 키로 암호화를 진행했다면, 복호화시에는 다른 키가 필요하다.

    위의 그림처럼 A키로 암호화를 하면 B키로만 복호화가 가능하다. 하여, HTTPS를 이용하는 프로토콜을 이용하는 서버는 한쌍의 키 중에서 하나는 비밀로 숨겨두고, 다른 하나는 클라이언트에게 공개해서 데이터를 안전하게 전송할 수 있게 한다.

    다만, 모든 통신에 대해서 공개키 방식을 사용하는 것은 아니다. 공개 키 방식은 많은 클라이언트를 대상으로 매번 사용하기에는 연산이 매우 복잡한 알고리즘이기 때문에 통신의 초창기에서만 비밀 키로 사용하기 위한 키를 만들어내기 위해서 사용한다.(즉, 처음 통신을 할 때 비밀키를 만든다.)

    통신 과정에서 각 부분은 위와 같이 Hand Shake, 비밀 키 생성, 상호 키 검증으로 나뉘게 된다.

    1. Hand Shake 부분에서는 서로를 확인하고 서버는 클라이언트에게 한쌍의 공개 키중 하나를 전달한다.
    2. 클라이언트는 전달받은 키를 이용해서 서버와 키를 만들어낼 임의의 정보를 암호화해서 서버에 전송한다.
    3. 이에 서버는 클라이언트와 마찬가지로 임의의 정보를 암호화해서 전송한다.
    4. 클라이언트 및 서버는 서로 교환한 임의의 정보를 바탕으로 비밀키를 생성하게 된다.
    5. 각자 생성한 키를 갖고 클라이언트가 테스트용 데이터를 바탕으로 만들어낸 비밀키로 암호화 하여 전달한다.
    6. 서버역시 만들어진 비밀키로 복호화하고, 다시 암호화 하여 클라이언트로 전달한다.
    7. 만약 클라이언트가 같은 내용의 데이터를 복호화하는데 성공하였다면 성공적으로 비밀키가 만들어진 상태인 것이다. 또한, HTTPS의 연결이 성립한 상태가 되는 것이다.
    8. 이후에 이 비밀키를 바탕으로 정말로 데이터 송수신이 필요한 동일키 암호화 및 복호화를 진행한다.

Learn About HTTPS

HTTPS 프로토콜


HTTPS(Hyper Text Transfer Protocol Secure Socket layer)는 HTTP over SSL(TLS), HTTP over Secure라고 부르기도 한다. HTTPS는 HTTP 요청을 SSL 혹은 TLS라는 알고리즘을 이용해, HTTP 통신을 하는 과정에서 내용을 암호화하여 데이터를 전송하는 방법입니다.

  • SSL과 TLS방식 알고리즘

참조

TLS(SSL) - 1. TLS의 암호화 방식(대칭키, 비대칭키)

TLS(SSL) - 2. 인증서, CA, SSL 인증서를 통해 서버를 인증하는 방법

TLS(SSL) - 3. Handshake

HTTPS와 SSL 인증서, SSL 동작방법

인증에서 HTTPS 프로토콜을 사용해야만 하는 이유는 HTTP보다 상대적으로 안전한 방법이고, 데이터 제공자의 신원을 보장받을 수 있기 때문이다. 데이터 제공자의 신원을 확인하고 보장받는게 인증에서 중요한 이유는 다음과 같다.

  • 클라이언트는 데이터 제공자가 제공해준 데이터를 사용할 수 밖에 없다. 클라이언트는 서버에 데이터 요청을 하고 이후 받은 데이터를 이용해서 화면을 렌더링하는 등의 작업을 해야 한다. 그렇기 때문에 요청 및 응답을 중간에서 가로채는 *중간자 공격(Sniffing👀)에 취약해 진다. 중간자 공격은 클라이언트와 서버 사이에서 공격자가 서로의 요청, 응답의 데이터를 탈취 및 변조하여 다시 전송하는 공격이다. 데이터가 중간에 다른 도메인을 거쳐서 전달되기 때문에 서버가 해당 데이터는 https://example.com 도메인에서 제공되었습니다. 라는 추가 데이터를 응답 객체에 실어 보낸다면 중간자 공격으로 인해 다른 도메인에서 데이터를 받은 클라이언트는 데이터를 제공한 도메인과 전달 받은 내용의 도메인을 비교하여 중간자 공격이 존재하는지 아닌지 확인할 수 있다.

암호화


HTTPS 프로토콜의 특징 중 하나는 암호화된 데이터를 주고 받기 때문에 중간에 인터넷 요청이 탈취되더라도 그 내용을 알아볼 수 없다. 기존에 배웠던 HTTP 프로토콜 요청 및 응답을 탈취한다면, 프로그램을 이용하여 아래와 같이 해당 요청으로 전달되는 데이터의 내용을 확인할 수 있다.

아래의 사진은 데이터를 전송하는 요청을 'wireshark'라는 패킷 분석 프로그램을 이용하여 캡처한 사진이다.

이 사진을 보게 되면 해당 email과 password 등, 중요한 데이터가 모두 노출되게 된다. 하지만 데이터를 암호화 하여 전송하는 HTTPS 프로토콜을 사용한다면 비밀번호와 같은 중요한 데이터가 유출될 가능성이 HTTP 프로토콜 보다 현저리 적어지게 된다.

아래의 사진은 위의 사진에서 똑같은 요청을 프로토콜만 HTTPS로 변경했을 때의 데이터를 캡처한 사진이다.

위와 아래의 사진과는 다르게 데이터의 내용이 암호화로 전송되기 때문에 정확한 키로 복호화하기 전까지는 어떤 내용인지 알 수 없다.

인증서


HTTPS 프로토콜의 또 다른 특징 중 하나는 브라우져가 응답과 함께 전달된 인증서 정보를 확인할 수 있다는 점이다. 브라우져는 인증서에 해당 인증서를 발급한 CA정보를 확인하고 인증된 CA가 발급한 인증서가 아니라면 아래와 같이 화면에 경고창을 띄워 서버와 연결이 안전하지 않다는 화면을 보여준다.

이렇게 브라우져는 인증서의 도메인과 데이터를 제공한 제공자의 도메인을 비교할 수 있기 때문에 인증서의 모데인 정보와 데이터 제공자의 도메인 정보가 다른 중간자 공격을 감지하여 보안 위협으로 부터 사용자 및 사용자의 데이터를 보호할 수 있다.

또한, 위와 같은 경고를 직접 보여줌으로써 브라우져들은 인증된 CA가 발급한 인증서를 이용하여 데이터를 제공하는 안전한 서버를 사용할 수 있게 사용자를 유도한다.

profile
궁금한걸 찾아보고 공부해 정리해두는 블로그입니다.

0개의 댓글

관련 채용 정보