DevOps13일차 - HTTPS

HTTPS 프로토콜

HTTPS는 Hyper Text Transfer Protocol Secure Socket layer 의 약자입니다. HTTP over SSL(TLS), HTTP over Secure라고 부르기도 합니다.

HTTPS는 HTTP 요청을 SSL 혹은 TLS라는 알고리즘을 이용해, HTTP 통신을 하는 과정에서 내용을 암호화하여 데이터를 전송하는 방법입니다.

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

데이터 제공자의 신원을 확인하고 보장받는게 인증에서 중요한 이유는 다음과 같습니다.

클라이언트는 데이터 제공자가 제공해준 데이터를 사용할 수밖에 없습니다.
클라이언트는 서버에 데이터 요청을 하고 이후 받은 데이터를 이용해서 화면을 렌더링하는 등의 작업을 해야 합니다.

그렇기 때문에 요청 및 응답을 중간에서 가로채는 중간자 공격에 취약합니다.
'중간자 공격'은 클라이언트와 서버 사이에서 공격자가 서로의 요청, 응답의 데이터를 탈취 및 변조하여 다시 전송하는 공격입니다.

데이터가 중간에 다른 도메인을 거쳐서 전달되기 때문에 서버가 해당 데이터는 https://example.com 도메인에서 제공되었습니다.라는 추가데이터를 응답객체에 실어 보낸다면 '중간자 공격'으로 인해 다른 도메인에서 데이터를 받은 클라이언트는 데이터를 제공한 도메인과 전달받은 내용의 도메인을 비교하여 '중간자 공격'이 존재하는지 아닌지 확인할 수 있습니다.

물론 중간자 공격으로 인해 이런 추가 데이터 또한 변조할 수 있습니다.
따라서 해당 데이터를 암호화시키는 작업이 필요합니다.

암호화

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

하지만 데이터를 암호화하여 전송하는 HTTPS 프로토콜을 사용한다면 비밀번호와 같은 중요한 데이터가 유출될 가능성이 HTTP 프로토콜보다 현저히 적어지게 됩니다. 아래 사진은 위 사진에서 똑같은 요청을 프로토콜만 HTTPS로 변경했을 때의 데이터를 캡처한 사진입니다.

보시는것처럼 내용이 암호화되어 전송되기 때문에 정확한 키로 복호화 하기전까지는 어떤 내용인지 알 수 없습니다.

인증서

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

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

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

대칭 키 비대칭 키

대칭 키

• 메시지를 보내는 쪽과 메시지를 받는 쪽이 메시지를 암호화하고, 이를 다시 메시지로 바꾸는 즉, 복호화와 같은 방식을 공유

  • 상대방에게 보내고자 하는 메시지를 ‘키’와 함께 알고리즘에 넣고 돌리면 암호문이 만들어짐

  • 이 암호문을 해독하려면 ‘키’ 값을 알고 알고리즘을 거꾸로 돌리면 됨

    이 과정을 복호화라고 부름

    즉 ‘키’ 값을 알지 못하면 절대 암호문을 해독할 수 없음

• 서버와 클라이언트가 똑같은 키(대칭 키)를 가지고 있어야 로그인 할 때 실어 보내는 비밀번호를 암호화 하고 해독 할 수 있음

문제점 : 그렇다면 이 ‘키’ 값을 애초에 어떻게 양쪽이 공유하는지

• 결국 한 번은 한쪽에서 다른 한 쪽으로 이 ‘키’를 전송해야 하는데 중간에 이 ‘키’를 누가 훔쳐본다면, 보안 상으로 문제가 생김.
  • 이것이 대칭 키의 한계

그러하여 생긴 게

비대칭 키 (공개키)

• A키로 암호화 한 텍스트를 B키로만 복호화 할 수 있음

  • 반대로 B키로 암호화 한 텍스트는 A키로만 복호화 가능

    즉, 서버에서 이 두 키들 중 하나는 비밀로 보관하고(개인키), 다른 한 키를 누구나 볼 수 있도록 공유 함

    사용자는 공개키로 암호화를 해서 서버에 개인 정보를 보냄

  • 개인 키를 가진 서버만 이 암호화 된 개인 정보를 알아 낼 수 있음

    신뢰할 수 있는 기관에서 이 공개키만 검증을 해준다면 그 키를 기준으로 안전하게 사이트를 이용 할 수 있음.

공개키가 정품인지 확인 하는 방법

• 이 키를 인증을 해주는 공인된 민간 기업들이 있음
  • Certificate Authority 줄여서 CA 라고 부름 (엄격한 인증 과정을 거쳐야 CA를 할 수 있음)

클라이언트와 서버가 서로를 신뢰하는 과정

• handshack (악수)
  • 클라이언트가 어떤 랜덤 데이터를 생성해서 서버로 보냄
  • 랜덤 데이터를 받은 서버는 답변으로 서버 측에서 생성한 무작위의 데이터와 해당 서버의 인증서를 실어 보냄
    • 클라이언트는 이 인증서가 진짜인지 브라우저에 내장된 CA들의 정보를 통해 확인 하게 됨 (비대칭 키 시스템 사용)
      • CA의 인증을 받은 인증서들은 해당 CA의 개인 키로 암호화 되어있음

        • 만약 이 인증서가 진짜라면 브라우저의 저장된 CA의 개인 키로 복호화 할 수 있게 됨

          CA 리스트 중에 이 인증서가 해당하는 것이 없다면 브라우저 창에 ‘경고’ 표시가 뜸

하지만, 비대칭 키 방식으로 메시지를 암호화 및 복호화 하는 건 대칭 키로 할 때보다 컴퓨터에 훨씬 큰 부담이 됨

그러하여 대칭 키 방식과 비대칭 키 방식을 혼합하여 사용하게 됨

• 대칭 키를 공유할 때 비대칭 키를 사용함
  • handshack 과정에서 생긴 데이터를 혼합하여 임시 키를 생성
  • 임시 키를 서버의 공개키로 암호화 해서 서버로 보낸 다음 일련의 과정을 거쳐 동일한 공개 키를 가짐
    • 이 공개키는 클라이언트와 서버만 알고 있으니 이후 서로 주고 받아지는 메시지들을 제 3자가 알아 볼 수 없음