오늘은 HTTPS에 대해서 알아보도록 하겠습니다....
사실 HTTPS를 설명하기 위해서 HTTP를 해왔던거라고 보시면 됩니다..
왜냐하면 3차프로젝트에서 HTTPS로 배포해야하는 상황이었는데, 그게 잘 안되고 찾아볼 레퍼런스도 부족해서 얘를 완벽하게 이해하고 접근해야겠다는 생각에 다시 공부하기로하고 공부를 끝내고 적고있는겁니다,,,ㅎ
그럼 시작해 보겠습니당!!
일단 HTTPS?? 간단하게 말하자면 암호화된 HTTP입니다.
그럼 먼저 암호화가 무엇인지부터 알고 가는게 좋겠죠?
1. 암호화
암호화는 승인된 당사자만 정보를 이해할 수 있도록 데이트를 "스크램블"한 방법입니다. 이를 복호화하려면 송신자와 수신자가 서로 동의한 "key"가 필요합니다. 또한 이를 만들기 위한 키가 쓰이기도 합니다. ciphertext=plaintext+key
(1) 스크램블
각 단어나 문자를 패턴에 따라 암호화하는 것이 아니라 무작위 방식으로 개별 데이터 비트를 섞는 것을 말합니다.
예를 들어, 공통 128비트 고급 암호화표준(Advanced Encryption Standard, AES)으로 암호화된 파일의 경우 이 파일을 구성하는 비트는 약 10회 스크램블되며 다른 컴퓨터가 키 없이 해독하려면 아주 오랜 시간이 걸리겠죠? 비트가 높아질수록 스크램블을 많이 하게 되고, 더 복잡해 집니다.
(2) 대칭 암호화
대칭 암호화는 키를 하나만 사용하는 암호화 방법입니다. 예를들어 "hello"라는 텍스트를 키로 암호화한다고 합니다. 동일한 키로 암호를 해독해서 hello를 반환한 것을 볼 수 있습니다. 일반적으로 사용되는 대칭 암호화 알고리즘은 DES,AES가 있습니다.
(3) 비대칭 암호화(=공개키 암호화)
두개의 다른 키(공개키, 개인키)로 데이터를 암호화하거나 서명하고 키 중 하나인 공개키를 누구나 사용할 수 있도록 하는 방법입니다. 공개키로 암호화된 데이터는 개인키로만 복호화 할 수 있게 합니다. 일반적으로 사용되는 비대칭 암호화 알고리즘은 RSA, DH(Diffe-Hellman)이 있습니다.
HTTPS를 가능하게하는 프로토콜인 TLS는 부분적으로 비대칭 암호화를 사용합니다. 비대칭암호화로 인증을 한 후, 대칭 암호화로 보안적 통신을 시작합니다.
TLS 핸드셰이크 과정에서 처음 인증할 때 비대칭 암호화를 하고 그 이후 클라이언트와 서버는 "세션키"라고 하는 키를 기반으로 대칭 암호화를 기반으로 하는 암호화된 통신을 합니다.
(4) 암호화의 필요성
암호화는 의도된 수신자 또는 송신자를 제외하고는 통신을 하이재킹(가로채기)하여 읽을 수 없게합니다. 이를 통해 민감한 데이터의 유출을 방지하고 데이터 무결성(데이터의 정확성과 일관성)을 보장합니다.
2. TLS 핸드셰이크
SSL(Secure Socket Layer)은 SSL 1.0 부터 시작해서 SSL 2.0, SSL 3.0, TLS(TransportLayer Security Protocol) 1.0, TLS 1.3 버전이 올라가며 마지막으로 TLS로 명칭이 변경되었습니다.
TLS는 전송계층에서 보안을 제공하는 프로토콜 입니다. 클라이언트와 서버가 통신할 때 TLS를 통해 제3자가 메시지를 도청하거나 변조하지 못하도록 합니다.
어떻게 암호화된 통신을 할거냐에 대해서 기초과 되는게 TLS HandShake과정이라고 보면 됩니다!!(점선 위까지!!)
TLS HandShake과정에서는 사용할 TLS버전을 정하고, 사이퍼 슈트, 서버의 공개키, SSL인증서를 기반으로 인증작업을 수행합니다. 이후 대칭 암호화를 위해 세션키를 생성합니다!
- 1. Client Hello
- 클라이언트는 TLS버전, 사이퍼슈트와 클라이언트 랜덤값(무작위 문자열), 임시 DH매개변수를 서버에게 보냅니다.
- 2. Server Hello, EncryptedExtensions, Certificate, CertificateVerify
- 서버는 클라이언트로부터 받은 옵션을 확인합니다. 서버와 클라이언트 모두에서 지원하는 가장 높은 TLS버전을 식별하며 결정, 사이퍼슈트 지원 여부를 확인합니다. 공개키가 포함된 SSL인증서, 서버 랜덤값, 임시 DH 매개변수를 보냅니다. 그리고 클라이언트와 서버 각각 서로 교환한 DH 매개변수를 사용하여 임시 암호 키(세션키(대칭암호화))를 생성합니다.
- 3. Finished
- 클라이언트와 서버가 세션키를 기반으로 대칭 암호화된 통신이 시작됩니다. (=보안세션 시작)
- 키 교환 알고리즘으로는 대표적으로 RSA와 DH가 있습니다. (TLS 1.3버전에서는 RSA같은 경우 취약점이 있기 때문에 공식적으로 지원하지 않습니다. DH의 경우 타원곡선을 사용.)
(1) DH 매개변수
DH는 Diffie-Hellman을 의미.
Diffie-Hellman알고리즘은 서로 공개값 공유, 비밀값과 혼합, 혼합값과 공유, 각자의 비밀값과 혼합해서 공통의 암호키를 만드는 알고리즘
DH는 그냥 디피헬만을 사용하는 DHE와 타원곡선암호화 방법과 DH를 섞은 ECDHE가 있고 보통 ECDHE를 사용합니다.
타원곡선암호화?? 곡선을 사용하여 개인 키 보유자만 알 수 있는 타원곡선을 그립니다. 이걸 기반으로 교차점을 생성해서 이 교차점의 수를 기반으로 암호를 설정하는 방법을 말합니다.
(2) 사이퍼슈트(=암호제품군)
: 프로토콜, AEAD 사이퍼모드, 해싱 알고리즘이 나열된 규약을 말하며 암호제품군이라고도 불립니다. TLS1.3 버전에서는 다섯개
ex) TLS_AES_128_GCM_SHA256
-TLS: 프로토콜
-AES_128_GCM: AEAD 사이퍼모드
-SHA256: 해싱 알고리즘
- AEAD 사이퍼모드
- AEAD(Authenticated Encryption with Associated Data)는 데이터 암호화 알고리즘
- ex. AES_128_GCM은 128비트의 키를 사용하는 표준 블록 암호화 기술과 병렬 계산에 용이한 암호화 알고리즘 GCM이 결홥된 알고리즘을 뜻함
- 해싱 알고리즘
- 데이터를 추정하기 힘든 더 작고, 섞여 있는 조각으로 만드는 알고리즘
- SSL/TLS는 해싱알고리즘은로 SHA-256 알고리즘과 SHA-384알고리즘을 쓰는데, 그 중 많이 쓰는 건 전자임
- 전자는 해시 함수의 결과값이 256비트인 알고리즘이며, 비트코인을 비롯한 많은 블록체인 시스템에서도 사용됨
- 해싱알고리즘은 인증서가 올바른 인증서인지 확인할 때 전자서명을 이용하는데 이 떄 해싱 알고리즘이 사용됨
- 1. 인증 생성작업: 전자서명을 만드는데 서명되는 메시지를 해싱
- 2. 인증 확인작업: 메시지를 복호화해서 해시를 서로 비교해 올바른 메시지인지 확인
- 전자서명이라함은 송신자가 자신의 신원을 증명하는 절차 또는 정보를 말함. 전자서명을 통해 인증서에 적힌 주체가 "서비스 제공자"인지 확인하고 인증서에 기록된 전자서명을 기반으로 CA의 공개키로 복호화해서 지문을 얻고 인증서에 기록된 정보들을 해시 함수에 입력해서 해시를 얻어내서 두 해시의 일치여부를 확인합니다. 이를 통해 두 지문이 일치한다면 인증서 자체가 변조된 적이 없는 것을 뜻합니다. 이를 통해 인증서의 유효성을 검증합니다. 즉, 유효성 검증이란 인증서가 변조되지 않았고, 인증서가 "서비스제공자"것임을 확인하는 절차입니다.
(3) 인증서
1. 주체(인증서 발급한 CA, 도메인, 웹사이트 소유자, 인증서 소유자)
2. 공개키(공개키, 공개키암호화방법)
-> 1,2를 포함한 단순한 데이터 파일
자신의 웹사이트 안에서 SSL인증서를 만들수도 있지만, 보통은 인증기관인 CA에서 발급한 SSL인증서를 기반으로 인증작업을 수행합니다.
주체는 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지 확인할 때 쓰고, 공개키는 처음 인증작업을 수행할 때 쓰입니다.
(4) CA
인증서의 역할은 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지를 보장하는 역할을 합니다. 이 인증서를 발급하는 기업들을 CA(Certificate Authority)라고 합니다. 참고로 서비스이 도메인, 공개키와 같은 정보는 서비스가 CA로부터 인증서를 구입할 때 제출해야합니다.
인증서는 다양한 유형의 인증서가 있습니다.
- 단일 도메인: 단 하나의 도메인에 적용되는 인증서
- 와일드 카드: 도메인의 하위 도메인도 포함하는 인증서, 예를 들어 www.cloudflare.com, blog.cloudflare.com 같은 것들
- 멀티 도메인: 이름이 의미하는 것처럼 멀티 도메인 SSL 인증서는 관련되지 않은 다수의 도메인에 적용될 수 있는 인증서
3. RSA의 취약점
RSA의 경우 클라이언트가 생성한 임시 암호값을 서버로 전송하지만 DH의 경우 클라이언트와 서버가 서로 교환한 DH매개변수를 사용해 개인키를 만듭니다. 이 때문에 RSA는 클라이언트에서 생성한 임시 암호값이 탈취당한 경우 해킹의 위험이 있습니다.
그러나 DH의 경우 탈취당해도 공통의 암호키를 못 만들기 때문에 더 좋은 것입니다.
(1) 0-RTT
세션키가 생성된 이후 다시 그 사이트에 방문한다면 미리 만들어놓은 세션키(PSK, pre-shared key)를 기반으로 연결을 생성하기 때문에 이때 인증에 드는 비용은 없습니다.
즉, 인증에 관한 RTT가 발생되지 않기 때문에 0-RTT라는 특징을 갖습니다.
네트워크상 보안을 해야하는 이유는 신용카드 등 민감한 금융정보를 다루는데 이점이 있고, HTTP/2는 HTTPS위에서만 돌아가기 때문입니다.
웹사이트가 SSL을 잘 수행하는지는 (https://www.ssllabs.com/ssltest/)에서 확인할 수 있습니다. 참고로 구글이 B라고 합니다..!
여기까지 해서 HTTPS에 대해서 알아보았습니다!!
길었지만 지금까지의 내용을 정리해보자면...
이 사진 정도로 정리해볼 수 있겠네요 ㅎㅎ
부디 도움이 되었길 바라며,,, 제 머릿속에도 잘 정리가 되었길 바라며,,, 오늘 포스팅을 마무리해 보겠습니다!
'네트워크' 카테고리의 다른 글
RefreshToken & AccessToken (0) | 2024.02.19 |
---|---|
Session VS JWT Token (0) | 2024.02.19 |
[네트워크] HTTP 심화-(2)HTTP/2 vs HTTP/3 (3) | 2024.01.25 |
[네트워크] HTTP 심화-(1)HTTP/1.0 vs HTTP/1.1, keep-alive, HOL (2) | 2024.01.25 |
[네트워크] HTTP기본 (1)HTTP헤더 (2) | 2024.01.25 |