HTTPS

만화로 알아보는 HTTPS

HTTPS

HTTP

하이퍼 텍스트 전송 프로토콜(Hypertext Transfer Protocol). 서로 다른 시스템들 사이에서 통신을 주고받게 해주는 기초적인 프로토콜.

HTTPS

HTTPS는 HTTP에다 SSL/TLS를 사용해 보안을 강화한 프로토콜. HTTPS 프로토콜은 SSL(Secure Socket Layer)/TLS(Transport Layer Security Protocol)을 사용함으로써 문제를 해결했습니다. 서버와 브라우저 사이에 안전하게 암호화된 연결을 만들 수 있게 도와주고, 서버 브라우저가 민감한 정보를 주고받을 때 이것이 도난당하는 것을 막아줍니다.

SSL/TLS

HTTPS란 HTTP에 SSL/TLS를 사용해 보안을 강화한 HTTP기 때문에, 여기서 중점적으로 SSL/TLS를 알아보도록 하겠다.

명칭

SSL(Secure Socket Layer)은 SSL 1.0부터 시작해 2.0 , 3.0을 거쳐 TLS(Transport Layer Security Protocol)로 명칭이 변경되고 1.0, 1.1, 1.2, 1.3(최신)으로 발전.

1. SSL은 넷스케이프에 의해 작성된 프로토콜이다. 이후 넷스케이프가 IETF (Internet Engineering Task Force)에 SSL 프로토콜을 제어권을 넘겼다.
2. 1999년이 끝나기 전에 IETF는 TLS 버전 1.0을 발표했어.(실제로 SSL 3.1 이었음)
   여기서 오늘날 까지도 SSL/TLS는 명칭때문에 혼란을 주고 있다.

결론

• SSL은 90년대 중반 넷스케이프에 의해서 생성된 오리지날의 하지만 폐기된 프로토콜(SSL 3.0은 2015년 공식적으로 사용 종료)
• TLS는 IETF에서 유지, 관리하는 웹의 보안 암호화를위한 새로운 프로토콜
• 현재 웹 브라우저들은 TLS 1.0, 1.1도 지원 종료(2020년) , 사용되고 있는 버전은 1.2나 1.3버전.
• SSL/TLS로 부르면 됨.

HTTPS는 왜 필요할까??

1. 신뢰성 : 방문자는 URL에 표시되는 녹색 자물쇠로 인해 웹사이트가 보안에 민감한 웹사이트임을 항상 신뢰할 수 있습니다.
2. 무결성 : HTTPS를 통해 전송되는 데이터는 항상 암호화됩니다. 따라서 정보가 안전합니다. 만약 해커가 공격을 통해 정보를 얻는 데 성공하더라도 데이터가 이미 암호화되어 있기 때문에 사용할 수 없습니다.
3. 식별 : 웹에서의 식별은 방문하는 사이트가 실제로 내가 생각하는 사이트임을 의미. HTTPS를 사용하는 경우 사용자는 자신의 데이터가 승인되지 않은 사이트가 아닌 올바른 위치로 전송되는지 확인할 수 있습니다
4. 데이터 검증 : HTTPS는 handshking을 통해 데이터 검증 과정을 수행. 데이터 전송은 유효성 검사가 성공한 후에만 발생합니다. 그렇지 않으면 프로세스가 종료됩니다.
5. 보호 : 클라이언트 시스템에 데이터를 저장하는 HTTP와 달리 HTTPS는 클라이언트 시스템에 사용자 데이터를 저장하지 않습니다. 따라서 공공장소에서의 데이터 도난에 대한 방지를 제공합니다..

HTTPS의 보안 방법

SSL/TLS는 보안 세션을 기반으로 데이터를 암호화하며, 세션이 만들어 질때 다양한 암호화 방법을 사용합니다.

보안세션 : 보안이 시작되고 끝나는 동안 유지되는 세션. SSL/TLS는 Handshake를 통해 보안 세션을 생성하고 이를 기반으로 상태 정보 등을 공유.

암호화 알고리즘

1. 대칭키 : 메시지를 암호화 하고 해독하는 키가 하나만 있다. 키를 가지고 있는 사람과 그 키의 복사본이 있는 사람만이 상자를 열고 메시지를 읽을 수 있다.
   => 키 배포 방법에 매우 주의해야 한다.

2. 비대칭키 : 키가 두개 있다. 하나는 public key(공개 키) 하나는 private key(비공개 키)

• public 키와 private 키는 서로 짝을 이루고 함께 동작한다.
• public 키는 말 그대로 공개용.
• 사용자는 public 키를 공개한다. 데이터가 사용자에게로 올때 이 public 키를 이용해서 암호화해 온다.
• 이 public 키를 이용해 암호화된 자료는 private 키를 가지고 있는 사용자만 열수있다.

클라이언트와 서버간의 협상 프로세스 - Handshake

• 맨 윗줄의 SYN, SYN ACK, ACK는 TCP layer의 3-way handshake로 HTTPS가 TCP 기반의 프로토콜이기 때문에 암호화 협상(SSL Handshake)에 앞서 연결을 생성하기 위해 실시하는 과정이고 아래 노란색 상자의 패킷들이 SSL Handshake입니다.

1. Client Hello

Client가 Server에 연결을 시도하며 전송하는 패킷입니다. 자신이 사용 가능한 Cipher Suite 목록을 전달합니다. Cipher Suite는 SSL Protocol version, 인증서 검정, 데이터 암호화 프로토콜, Hash 방식 등의 정보를 담고 있는 존재로 선택된 Cipher Suite의 알고리즘에 따라 데이터를 암호화하게 됩니다.

<Cipher Suite의 구성>

2. Server Hello

Client가 보내온 ClientHello Packet을 받아 Cipher Suite 중 하나를 선택한 다음 Client에게 이를 알립니다. SSL/TLS버전 및 암호화 알고리즘을 서버의 선호도에 따라 선택하고, 서버의 공개키가 포함된 인증서로 회신하여 '식별'도 가능.

3. Certificate

Server가 자신의 SSL 인증서를 Client에게 전달합니다. 인증서 내부에는 Server가 발행한 공개키가 들어있습니다. Client는 Server가 보낸 CA(Certificate Authority, 인증기관)의 개인키로 암호화된 이 SSL 인증서를 이미 모두에게 공개된 CA(Certificate Authority, 인증기관)의 공개키를 사용하여 복호화합니다. 이때 복호화에 성공하는 것은 인증서를 검증하는 것과 마찬가지.

또한 Client는 데이터 암호화에 사용할 대칭키를 생성 해서 서버의 공개키를 이용해 암호화해 Server에게 보냄.

4. Server Key Exchange / ServerHello Done
'Server Key Exchange'는 Server의 공개키가 SSL 인증서 내부에 없는 경우, Server가 직접 전달함을 의미합니다. 공개키가 SSL 인증서 내부에 있을 경우 Server Key Excahnge는 생략됩니다. 인증서 내부에 공개키가 있다면 Client가 CA(Certificate Authority, 인증기관)의 공개키를 통해 인증서를 복호화한 후 Server의 공개키를 확보할 수 있습니다. 그리고 Server가 행동을 마쳤음을 전달합니다.

5. client Key Exchange
대칭키를 Client가 생성하여 SSL 인증서 내부에서 추출한 Server의 공개키를 이용해 암호화한 후 Server에게 전달합니다. 여기서 전달된 '대칭키'가 바로 SSL Handshake의 목적이자 가장 중요한 수단인 데이터를 실제로 암호화할 대칭키입니다. 이제 키를 통해 Client와 Server가 교환하고자 하는 데이터를 암호화합니다.

Handshake 정리

ClientHello(암호화 알고리즘 나열 및 전달) - > Serverhello(암호화 알고리즘 선택) - > Server Certificate(인증서 전달) - > Client Key Exchange(데이터를 암호화할 대칭키 만들고 전달) - > Client / ServerHello done (정보 전달 완료) - > Fisnied (SSL Handshake 종료)

키 교환 방식(키 교환 알고리즘)

• RSA
  SSL 인증서에 서버의 공개키가 들어있다는 것은 서버가 대칭키(비밀키)를 암호화하기 위한 키 교환 알고리즘 선택 시 RSA를 선택했다는 것을 의미합니다. 왜냐하면 공개키가 있다는 것은 곧 서버가 공개키-개인키 쌍(RSA)을 생성하여 SSL 인증서 생성 시 공개키를 제출했기 때문이죠. 다시 말해 공개키 암호 방식을 선택한 것입니다. 그리고 SSL Handshake의 'Client Key Exchange' 과정에서 사용자는 서버의 공개키를 이용해 대칭키(비밀키)를 암호화하고 서버에 전달하게 됩니다.

• Diffie-Hellman(DH)
  Key Paramenter(이하 키 매개변수)만을 교환하면 동일한 대칭키(비밀키)를 얻을 수 있기 때문에 SSL 인증서 내부에 서버의 공개키가 존재하지 않습니다. 그리고 사용자와 서버는 SSL Handshake의 'Client Key Exchange'와 'Server Key Exchange'를 통해 서로 키 매개변수를 교환합니다.

안전한 HTTPS 연결을 보장하기 위해 따라야할 방법

• 인증 메커니즘 : CA에서 유효한 SSL/TLS 인증서를 발급받는다. 이러한 인증서는 사용자와 서버간의 데이터를 암호화를 활성화 하고, 서버 식별의 도구가 된다.

  • CA(Certificate Authority, 인증기관)
    • 누구나 신뢰할 수 있는 최상위 인증기관 아래 다수의 중간 인증기관을 두고 그 인증기관을 사용하는 SSL 인증서들. CA는 3계층 혹은 2계층 구조의 형태를 띄고 있습니다.
    • 사이트는 Intermediate CA에게서 검증을 받고, Intermediate CA들은 Root CA에게 검증받으며, Root CA는 스스로를 검증합니다. 이러한 인증서의 나열을 나타낸 것이 Certificate Chain(인증서 체인)
  • 브라우저
    • 브라우저는 인증서를 발급한 주요 인증기관의 리스트와 공개키를 이미 보유
    • 해당 인증서가 자신이 보유한 인증기관의 리스트 중 하나일 경우 이미 갖고 있는 공개키를 이용하여 인증서를 복호화
    • SSL 인증서를 사용할 때 최소한의 인터넷 접속이 필요한 이유가 이런 이유 때문

• PFS(Perfect Forward Secrecy) 완전한 순방향 비밀성

  • PFS는 공격자가 private 키를 탈취한 경우에도 과거와 미래의 통신이 안전하게 유지되도록 합니다.
  • PFS는 각 세션에 대해 임시 키 쌍을 생성하고 세션이 끝나면 폐기하여 키가 탈취 당해도 문제가 없도록 합니다.
  • DHE 키 교환 알고리즘의 특성을 사용하여 주기적으로 대칭키를 변경하여 특정 기간에는 특정한 대칭키로 데이터를 암호화하는 것

• HSTS(HTTP Strict Transport Security): HSTS는 브라우저가 HTTPS 연결만 사용하도록 하는 보안 기능입니다. 이는 중간자 공격의 위험을 줄이고 암호화되지 않은 HTTP 연결을 방지하는 데 도움이 됩니다.

SEO에도 도움이 되는 HTTPS

• SEO(Search Engine Optimization) : 검색엔진 최적화를 뜻하며 검색 엔진 결과 페이지(SERP)에서 웹 사이트의 가시성과 순위를 개선하는 과정입니다. SEO의 주요 목표는 사이트의 콘텐츠, 제품 또는 서비스와 관련된 관련 키워드 또는 문구를 검색하는 사용자가 웹사이트를 보다 쉽게 보고 액세스할 수 있도록 하여 웹사이트에 대한 트래픽을 늘리는 것입니다.

  사이트 내 모든 요소가 같을 시 HTTPS를 사용하는 서비스가 그렇지 않은(HTTP사용)사이트보다 검색 순위가 높을것이라고 구글에서 공식 적으로 밝혔다. 서비스의 성공을 위해서는 SEO 관리는 필수.