HTTPS

HTTPS 알아보기

1️⃣  들어가기 전 알고 넘어가기

대칭키(Symmentric Key) 암호화

• 대칭키 암호화 방식은 복호화에 같은 암호 키(대칭키)를 사용하는 알고리즘 입니다.

• 공개키 암호화 방식에 비해 암호화 및 복호화가 빠르다는 장점이 있습니다. 하지만 암호화 통신을 하는 사용자끼리 같은 대칭키를 공유해야만 한다는 단점이 존재합니다.

• 대칭키를 공유햐야만 하는것이 왜 단점일까? 빠르다며? 엉?
• 대칭키 암호화 방식은 암호화와 복호화가 비교적 간편합니다. 뿐만 아니라 대칭키를 사용자끼리 물리적으로 직접 만나서 전달하지 않는한, 대칭키를 전달하는 과정은 해킹의 위험에 노출될 수 있습니다.
• 그래서 공개키 암호화 방식이 등장했습니다.

공개키(Public Key) 암호화

• 공개키 암호화 방식은 암호화와 복호화에 사용하는 암호키를 분리한 방식입니다.

• 자신이 가지고 있는 고유한 암호키(Private Key)로만 복호화할 수 있는 암호키(Public Key)를 사용자들에게 공개합니다.

• 공개키 암호화 방식을 이용한 통신 시나리오
• A가 웹 상에 공개된 B의 공개키를 이용하여 평문을 암호화 합니다.
• 이 암호문은 B가 개인적으로 가지고 있는 B의 개인키로만 복호화가 가능합니다.
• B는 자신의 비밀키로 복호화한 평문을 확인하고 A의 공개키로 응답을 암호화하여 A에게 보냅니다.
• A는 또 자신의 개인키로 암호화된 응답문을 복호화하여 확인합니다.

• 이처럼 공개키 암호화 방식은 대칭키의 단점을 해결하도록 만들어졌습니다. 하지만 그만큼 단점이 존재하는데, 암호화와 복호화가 매우 복잡하다는 점 입니다.
• 복잡한 이유는 암호화하는 키와 복호화하는 키가 서로 다르기 때문입니다.

• 그래서 대칭키 암호화 방식과 공개키 암호화 방식을 적절히 혼합하여, 이론적으로 완벽한 암호화 방식이 고안되었는데, 그것이 바로 SSL의 시초가 되었습니다. 어떻게 혼합할까요?
• A가 B의 공개키로 암호화 통신에 사용할 대칭키를 암호화하여 B에게 보냅니다.
• B는 암호문을 받아 자신의 비밀키로 복호화합니다.
• B는 A로부터 얻은 대칭키로 A에게 보낼 평문을 암호화하여 A에게 보냅니다.
• A는 자신의 대칭키로 암호문을 복호화합니다.
• 계속해서 대칭키로 암호화 통신을 합니다.

• 정리하면, 대칭키를 주고 받을 때만 공개키 암호화 방식을 사용하고 이후에는 계속 대칭키 암호화 방식으로 통신하는 것입니다.

SSL(Secure Socket Layer)

• SSL은 넷스케이프사에서 전자상거래보안을 위해 개발한 암호화 방식입니다. 위에서 설명한 대칭키&공개키 통합 암호화 방식을 기본으로 한 암호화 방식이며, 통신하는 상대방이 해커가 아닌지 확인하기 위한 알고리즘이 더해집니다.
• 사이트(특히 전자상거래 기관)는 인증기관에 자신의 정보와 공개키를 제출합니다.
• 인증기관은 정보를 면밀히 검토한뒤, 사이트의 정보와 공개키를 자신의 비밀키로 암호화합니다.
• 인증기관은 인증기관의 비밀키로 암호화된 사이트의 정보와 공개키를 사이트에 송신합니다.
• 개인이 브라우저를 통해 사이트에 접속하면, 암호화된 사이트의 정보와 공개키를 사이트로 부터 받습니다.
• 브라우저는 인증기관의 공개키로 이를 복호화하여 사이트의 공개키를 얻습니다.
• 브라우저가 대칭키를 사이트의 공개키로 암호화하여 사이트에 보냅니다.
• 사이트는 자신의 개인키로 암호화된 대칭키를 복호화 합니다.
• 이제 개인과 사이트는 대칭키를 통해 통신할 수 있습니다.

SSL 인증서

• SSL 인증서는 클라이언트와 서버간의 통신을 제3자가 보증해주는 전자화된 문서입니다.

• 언제 검증할까?
• 클라이언트가 서버에 접속한 직후에 서버는 클라이언트에게 이 인증서 정보를 전달하게 되며 클라이언트는 이 인증서 정보가 신뢰할 수 있는 것인지를 검증 한 후에 다음 절차를 수행하게 됩니다.

• SSL 인증서의 역할
• 클라이언트가 접속한 서버가 신뢰할 수 있는 서버임을 보장합니다.
• SSL 통신에 사용할 공개키를 클라이언트에게 제공합니다.

• 인증서의 내용
• 서비스의 정보(인증서를 발급한 CA, 서비스 도메인 등등)
• 클라이언트가 접속한 서버가 신뢰할 수 있는 서버임을 보장하는 역할에 사용한다.
• 서버 측 공개키(공개키의 내용, 공개키의 암호화 방법)
• 서비스의 도메인, 공개키와 같은 정보는 서비스가 CA로부터 인증서를 구입할 때 제출하고, CA에 의해 암호화해서 저장(CA는 CA 공개키를 이용해서 서버가 제출한 인증서를 암호화)

CA(Certificate Authority)

• 인증서를 통해 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지를 보장하는 역할

• 브라우저의 CA 리스트
• 브라우저는 내부적으로 CA 리스트를 미리 파악하고 있습니다. 즉 브라우저가 미리 파악하고 있는 CA의 리스트에 포함되어야만 공인된 CA가 될 수 있습니다.

• 확인 결과 서버를 통해서 다운받은 인증서가 내장된 CA 리스트에 포함되어 있다면 해당 CA의 공개키를 이용해서 인증서를 복호화
• CA의 공개키를 이용해서 인증서를 복호화 할 수 있다는 것은 이 인증서가 CA의 비공개키에 의해서 암호화 된 것을 의미합니다.

2️⃣  HTTP(Hypertext Transfer Protocol)

• HTTP는 Hyper Text Transfer Protocol의 줄임말으로써, 서버와 클라이언트간에 데이터를 주고받는 프로토콜 입니다.

• HTTP는 텍스트, 이미지, 영상, JSON 등등 거의 모든 형태의 데이터를 전송할 수 있습니다.

HTTP는 보안적으로 안전할까?

• HTTP 통신은 클라이언트와 서버간의 통신에 있어서 별다른 보안 조치가 없기 때문에 만약 누군가 네트워클 신호를 가로챈다면 HTTP의 내용은 그대로 외부에 노출됩니다.

• 중요 정보가 없는 소규모의 프로젝트라면 문제가 되지 않겠지만 고객의 개인정보나 비밀을 취급하는 대규모 서비스라면 큰 보안적 허점이 될 것입니다.

• 이러한 문제를 해결하기 위해서 HTTPS가 등장합니다.

3️⃣  HTTP Request 구조

Start Line - HTTP Request의 첫 라인

• HTTP Method
• HTTP Method에는 GET, POST, PUT, DELETE, OPTIONS 등등 있습니다.

• Request Target
• 해당 request가 전송되는 목표 uri

• HTTP Version
• 말 그대로 사용되는 HTTP 버전, 버전에는 1.0, 1.1, 2.0 등이 있습니다.

headers - 해당 request에 대한 추가정보를 담고 있는 부분

• key-value값으로 되어 있습니다.

• HOST
• 요청이 전송되는 target의 host url: 예를 들어, google.com

• User-Agent
• 요청을 보내는 클라이언트의 대한 정보; 예를 들어, 웹브라우저에 대한 정보

• Accept
• 해당 요청이 받을 수 있는 응답타입

• Connection
• 해당 요청이 끝난후에 클라이언트와 서버가 계속해서 네트워크 컨넥션을 유지 할 것인지 아니면 끊을것인지에 대해 지시하는 부분

• Content-Type
• 해당 요청이 보내는 메시지 body의 타입, 예를 들어 JSON을 보내면 application/json

• Content-Length
• 메시지 body의 길이

Body - 해당 request의 실제 메시지/내용

• Body가 없는 request도 많다 예를 들어 GET request들은 대부분 body가 없는 경우가 많습니다.

4️⃣  HTTP Response 구조

Strart Line - 응답의 상태를 간략하게 나타내주는 부분

• HTTP 버전

• Status code : 응답 상태를 나타내는 코드, 숫자로 되어 있는 코드 예를들어 200

• Status text : 응답 상태를 간략하게 설명해주는 부분 에를 들어 “404 Not Found”

Headers

• HTTP Request의 Header와 동일합니다.
• 다만 response에서만 사용되는 header 값들이 있습니다.
• ex) User-Agent 대신에 Server 헤더가 사용

Body

• HTTP Response의 Body와 일반적으로 동일합니다

• Request와 마찬가지로 모든 response가 body가 있지는 않습니다.
• 데이터를 전송할 필요가 없을 경우 body가 비어있게 됩니다.

5️⃣  HTTPS = HTTP + SSL

HTTP의 문제

• 암호화 기능이 없다.
• 단순 text 형식으로 주고받기 때문에, 중간에서 누군가가 신호를 가로챈다면 내용이 그대로 노출된다.

• 신뢰할 수 있는 사이트인지 확인 불가
• 통신하려는 사이트를 따로 확인하는 작업이 없어 다른 사이트가 통신하려는 사이트로 위장 가능

• 통신 내용 변경 가능
• 요청을 보낸 곳과 받은 곳의 리소스가 정확히 일치하는지 확인할 수 없다.
• 누군가가 중간에 데이터를 악의적으로 변조한다면 정확한 데이터를 주고받을 수 없게된다.

HTTPS는 어떻게 해결했을까?

• 기존의 HTTP 프로토콜은 전송계층의 TCP 위에서 동작합니다. 여기서 SSL(Secure Sockets Layer)라는 보안 계층이 전송계층 위에 올라갑니다. HTTPS는 SSL 위에 HTTP를 얹어서 보안이 보장된 통신을 하는 프로토콜이며 이 통신 방식을 SSL 암호화 통신 이라고도 합니다.

• SSL 암호화 통신은 공개키 암호화 방식이라는 알고리즘을 통해 구현됩니다.

SSL - Secure Socket Layer

• HTTP 프로토콜 상위에 통신시 보안을 위한 SSL 관련 프로토콜이 있는 방식

SSL 적용 방식

• SSL 암호화 통신은 비대칭키 방식(암호화에 사용할 키를 교환)

• 데이터 통신은 대칭키 방식

• SSL 적용은 핸드 셰이킹 단계에서 발생이 된다.
• SSL 핸드셰이킹 : 443 포트를 이용하여 서로의 상태를 파악하는 TCP 기반의 프로토콜
• TCP 기반이기 때문에 SSL 핸드세이크 전에 TCP 3-way 핸드셰이크 또한 수행

• 핸드 셰이킹 순서
1. Client hello : 클라이언트가 서버에게 연락
• ex) 브라우저 검색창에 도메인을 입력하는 것
• 이때 클라이언트는 자신의 브라우저가 지원할 수 있는 암호화 방식(Cipher Suite)을 먼저 제시합니다. 그리고 랜덤 데이터를 생성하여 추가로 전송합니다.
• 세션 아이디 : 이미 SSL 핸드쉐이킹을 했다면 비용과 시간을 절약하기 위해서 기존의 세션을 재활용하게 되는데, 이때 사용할 연결에 대해 식별자를 서버 측으로 전성
2. Server hello : 서버가 클라이언트에게 연락
• 서버는 클라이언트가 제시한 암호화 방식 중 하나를 선정하여 알려줍니다.
• 또한, 서버 자신의 인증서를 전달합니다. 이 인증서에는 서버의 공개 키가 포함되어 있습니다.(public key)
• 클라이언트와 마찬가지로 서버 측에서 생성한 랜덤 데이터 또한 전달
3. Client key exchange
• 인증서가 자신이 신용있다고 판단한 CA로부터 서명된 것인지 확인합니다.
• 또한 날짜가 유효한지, 그리고 인증서가 접속하려난 사이트와 관련되어 있는지 확인
• 클라이언트는 미리 주고받은 자신과 서버의 랜덤 데이터를 참고하여 서버와 암호화 통신을 할 때 사용할 키(랜덤 대칭 암호화 키)를 생성한 후 서버에게 전달합니다.
• 이때 키는 서버로부터 받은 공개키로 암호화되어 보내집니다.
4. Finished
• 마지막으로 핸드셰이크 과정이 정상적으로 마무리되면, 클라이언트와 서버 모두 “finished”메시지를 보냅니다.
5. 이후 전송단계로 넘어가서 클라이언트가 생성한 키를 이용하여 암호화된 데이터를 주고받게 됩니다.

• 핸드 쉐이킹 이후 데이터 전송 과정
1. 클라이언트의 암호화한 데이터 전송
• public key를 사용해서 랜덤 대칭 암호화키를 비롯한 URL, http 데이터들을 암호화해서 전송
2. 웹서버의 복호화
• private key를 이용해서 랜덤대칭 암호화키와 URL, http를 복호화
3. 웹서버의 암호화 데이터 전송
• 요청받은 URL에 대한 응답을 웹브라우저로부터 받은 랜덤 대칭 암호화키를 이용하여 암호화해서 브라우저에 전송
4. 클라이언트의 복호화
• 대칭 암호키를 사용해서 http 데이터와 html 문서를 복호화하고 화면에 뿌려준다.

HTTPS 적용하기

1. 도메인 구입

• Route53 에서 도메인 등록을 클릭한다.

• 원하는 도메인 명을 입력하고 다음을 누른다.

• 마음에 드는걸로 선택해서 장바구니에 추가를 누른후 다음을 눌러 연락처를 및 정보를 입력하고 진행하면 도메인이 발급된다

• 도메인이 잘 생성된 모습을 볼 수 있다.

2. 인증서 발급받기

• aws의 ACM에 들어가서 인증서 요청 버튼을 클릭한다.

• 도메인 이름을 아래와 같은 형태로 추가한 후 DSN 검증을 선택하고 발급 요청을 한다.

• 인증서가 발급된 모습을 확인할 수 있습니다.
• 상태가 발급 대기중으로 시간이 조금 걸릴 수 있는데 기다리면 발급완료로 바뀝니다. 저는 15분정도 기다린 것 같아요 !

• 인증서로 들어가서 Route53에서 레코드 생성 버튼을 눌러주고 생성을 눌러주세요 ! 그럼 끗입니다 !

3. 로드밸런서 생성하기

• 로드밸런서 생성으로 들어가서 Application Load Balancer 생성을 누릅니다.

• 이름과 리스너를 HTTPS를 추가해 줄게요

• 가용영역은 EC2 가용영역 최소 2개를 선택해주세요

• 다음을 눌러서 인증서와 보안그룹을 선택해주세요 !

• 대상그룹은 저는 8080포트를 이용하고 있어서 8080으로 설정해 주었습니다. 다음을 누르고 등록할 EC2를 선택해주면 끝입니다.

• http 80포트로 들어오는 부분도 443으로 포워딩을 하고 싶다면 로드밸런서에 리스너탭에 들어가서 리스너 추가를 누르고 아래처럼 설정해 주시면 됩니다.

• 이제 마무리로 Route53에 들어가서 레코드 생성을 누르고 만든 로드밸런서를 대상으로 설정하고 생성을 해줍니다 !

• 끗