HTTPS에 대한 내용을 정리했습니다.
HTTP 보안 기술의 요구 사항, HTTPS 개요, 대칭키 암호법, 공개키 암호법, 디지털 서명, 디지털 인증서는 HTTPS의 동작 방식을 이해하기 위해 필요한 기본 지식입니다.
HTTP 보안 기술의 요구 사항
- 서버 인증 - 클라이언트가 위조된 서버가 아닌 진짜 서버와 통신 중이라는 것을 알 수 있어야 함
- 클라이언트 인증 - 서버가 진짜 클라이언트와 통신중임을 알 수 있어야 한다.
- 무결성 - 데이터가 위조되는것으로 부터 안전해야한다.
- 암호화 - 도청에 대한 걱정 없이 대화 할 수 있어야한다.
- 효율 - 저렴한 서버도 사용 가능하도록 알고리즘이 빨라야한다.
- 편재성 - 프로토콜이 거의 모든 클라이언트/서버에서 지원되야한다.
- 관리상 확장성 - 누구든 어디서든 즉각적인 보안 통신을 할 수 있어야한다.
- 적응성 - 현재 알려진 최선의 보안 방법을 지원해야 한다.
- 사회적 생존성 - 사회의 문화적, 정치적 요구를 만족시켜야 한다.
HTTPS 개요
- HTTPS는 HTTP를 안전하게 만드는 방법 중 가장 인기 있는 방법
- 넷스케이프 커뮤니케이션 주식회사에서 개척
- HTTPS는 HTTP 하부에 전송 레벨 암호 보안 계층을 제공하는 것이다.
이 보안 계층을 SSL/TLS라고 부른다.
SSL/TLS
- TLS: 전송 계층 보안 (Transport Layer Security)
- SSL: 보안 소켓 레이어 (Secure Sockets Layer)
- TLS는 SSL 3.0을 기반으로 개발되었다.
SSL의 업그레이드 버전이며 명칭만 변경된 것이기 때문에 SSL과 TLS를 혼용해서 사용한다.
대칭키 암호법
- 인코딩/디코딩에 동일한 키를 사용하는 방법
- DES, Triple-DES, RC2, RC4등의 알고리즘이 있다.
열거 공격
- 무차별적으로 모든 키 값을 대입해 보는 공격
- 대칭 키 암호에서 열거 공격으로 암호를 깨는데 필요한 시간은 키의 길이가 길수록 늘어난다.
- 1995년 기준 기술과 물가로 공격했을 경우, 아래 표와 같은 시간이 소요된다고 한다.
| 공격 비용 | 40비트 키 | 64 비트 키 | 128 비트 키 |
|---|---|---|---|
| 100000달러 | 2초 | 1년 | 10^19년 |
| 10000000달러 | 20밀리초 | 4일 | 10^17년 |
| 1000000000달러 | 200마이크로초 | 1시간 | 10^15년 |
단점
- 대칭키의 단점은 수신자와 송신자가 둘 다 공유 키를 가져야 한다는 것이다.
각각의 수신/송신 채널마다 비밀 키를 하나씩 생성해야만 한다.
N개의 노드가 N-1개의 노드와 통신하기 위해서는 N^2의 비밀 키를 관리해야 한다.
공개키 암호법
- 두 개의 비대칭 키를 사용한다.
클라이언트는 공개키를 사용하여 평문을 암호문으로 인코딩해서 서버에 전송한다.
서버는 개인키를 사용하여 암호문을 디코딩해서 평문으로 변경한다.
장점
- 공개키는 호스트당 하나만 생성되기 때문에 대칭키 처럼 관리해야 하는 키의 개수가 폭발적으로 늘어나지 않는다.
RSA
- 유명한 공개키 암호 체계이다.
- 큰 수의 소인수 분해가 어려움을 이용한 암호화 방식이다.
- 페르마의 소정리를 사용하여 비대칭 키를 생성하는데, 공개키만 가지고 개인키를 추론하는데에는 엄청난 시간이 걸린다.
혼성 암호 체계와 세션 키
- 공개키 알고리즘은 계산이 느리다.
이 단점을 해결하기 위해, 대칭키와 비대칭키를 섞어서 사용한다.
- 공개 키 암호로 통신 채널 수립
- 수립된 채널로 대칭 키 교환 후, 나머지 암호화는 대칭키 사용
디지털 서명
- 메시지에 붙어있는 특별한 암호 체크섬
- 메시지를 작성한 저자가 누군지 알려준다.
- 저자만이 개인키로 체크섬을 계산할 수 있다.
- 메시지 위조를 방지한다.
- 서버가 평문 메시지를 요약 한 후, 개인키로 암호화 한 것이 서명이다.
클라이언트가 서명을 공개키로 복호화 한 후, 평문 메시지를 요약한 것과 대조하여 메시지가 위조되었는지 확인한다.
디지털 인증서
- 주민등록증같은 인터넷 신분증이다.
- 신뢰할 수 있는 기관으로부터 보증받은 사용자/회사의 정보를 담고 있다.
- 아래 사진은 구글의 인증서 정보이며, 평문을 개인키로 서명한 지문(디지털 서명)을 가지고 있다.
- 대부분의 디지털 인증서는 X.509 v3 구조를 따른다.
인증서 확인 절차
- 브라우저는 자동으로 접속한 서버에서 디지털 인증서를 가져온다.
- 인증서를 받으면 서명 기관을 검사한다.
이때, 신뢰할 수 있는 서명기관이면 브라우저는 해당 기관의 공개키를 가지고 있다. - 디지털 서명의 무결성을 검증한다.
HTTPS 동작 방식
- URL의 스킴으로 https를 쓰면 서버의 443번 포트에 SSL 핸드셰이크를 수행한다.
- 위 그림의 번호대로 HTTPS가 작동한다.
브라우저의 인증서 검사 알고리즘
- 날짜 검사: 인증서가 만료되었거나 활성화 되지 않았는지 확인하기 위해 인증서의 시작 및 종료일을 검사
-> 유효하지 않으면 에러 발생 - 서명 신뢰도 검사: 인증기관(CA)가 브라우저가 신뢰할 수 있는 기관인지 확인
신뢰할 수 있는 CA가 간접적으로 서명한 인증서도 신뢰할 수 있다고 판단
-> 신뢰할 수 없으면 경고창 생성 - 서명 검사: 서명으로 인증서의 무결성 검사
- 사이트 신원 검사: 인증서의 도메인과 대화중인 서버의 도메인이 동일한지 검사
-> 다르다면, 에러 발생
Java/Kotlin Back-end Developer