본문 바로가기
Web hacking/개념 정리 & 심화

HTTPS 프로토콜의 모든 것(SSL인증서, SSL 피닝, TLS, HTTP 인증)

by m_.9m 2022. 12. 4.

2.1 HTTP 기본

HTTP는 HTML 문서와 같은 리소스를 가져올 수 있도록 해주는 프로토콜이다. HTTP는 웹에서의 모든 데이터 교환의 기초이며 클라이언트-서버간에 사용되는 프로토콜이다. 

 

 

HTTP는 애플리케이션 계층의 프로토콜로, TCP/IP 프로토콜을 통해 통신한다. (=tcp 기반으로 만들어진 프로토콜이다) HTTP는 확장성이 뛰어나 이미지, 비디오나 폼 결과를 서버로 POST 하기 위해서 도 사용돤다.

 

☑️ HTTP는 상태 비저장 프로토콜이지만 세션을 사용한다.

☑️ HTTP 기반 API로는 user agent와 서버간의 데이터를 교환하는데 사용될 수 있는 XMLHttpRequest API가 있다.

  • XHR 객체는 서버와 상호작용할 떄 사용한다. 페이지의 새로고침 없이도 URL에서 데이터를 가져올 수 있다. AJAX 프로그래밍에 많이 사용된다.

 

 

2.2 HTTP 버전의 진화

HTTP는 월드 와이드 웹에 내재된 프로토콜입니다. Tim Berners-Lee에 의해 1991년에 발명되었다. 월드 와이드 앱은 기존의 TCP/IP 프로토콜 상에서 만들어져 4개의 블록으로 이루어져 있다.

 

(1) 초기버전

초기버전은 HTTP/0.9라고 불리며 GET 메소드만 사용할 수 있었다. HTTP 헤더도 없어 HTML 문서만 전송할 수 있었다. 에러 발생 시 파일 내부에 문제 설명과 함께 돌려보내 이를 알렸다.

[요청]
GET /test.html

[응답]
<HTML>
simple page
</HTML>

 

(2) HTTP/1.0 - 확장성 만들기

버전 정보, 응답코드(200), 전송 확인 코드(status code) 추가로 결과에 대한 동작을 확인할 수 있게 되었다. Content-Type이 추가되며 HTML외의 다른 문서들 전송이 가능해졌다.

 

(3) HTTP/1.1 - 표준 프로토콜

✔️ 추가

☑️ Host 헤더의 추가로 동일 ip의 다른 도메인에 대한 접근이 가능.

☑️ 중첩 요청(Pipelining)이 가능해 시간을 단축시킴.

☑️ 컨텐츠 협상이 가능해 언어, 인코딩 혹은 타입에 대한 적합한 컨텐츠를 찾아 교환.

☑️ 커넥션 재사용 가능(Keep-Alive header)

이후 보안 전송을 위해 SSL 2.0, 3.0, 3.1이 제작 이후 TLS 1.0,1.1.1.2버전이 등장했다. 또한 복잡한 애플리케이션을 사용하기 위해 웹소켓, 서버 전송 이벤트와 같은 API로 인한 HTTP 확장을 만들었다.

 

✔️ 단점

☑️ HOL(Head of Line) Blocking

순차적으로 응답을 받기 때문에 발생.

☑️ RTT(Round Trip Time) 증가

일반적으로 Connect 하나에 요청 한개를 처리해서 3-Way Handshake가 지속적 발생.

☑️ 무거운 헤더로 인한 성능 저하

 

 

(4) HTTP/2

구글의 SPDY 프로토콜을 기반으로 개발되었다.

 

☑️ 항상 TLS 사용

☑️ HTTP의 Hearder 압축

☑️ 텍스트가 아닌 바이너리 프로토콜

☑️ Multiplexed Streams

한번 요청에 다중전송이 가능하다. 3 TCP > 1 TCP로 한꺼번에 전송이 가능함.

 

 

2.3 HTTP 메세지

HTTP 메세지는 ASCII로 인코딩한 텍스트 정보로구성되어 있다.

(1) Request Start Line

✔️ HTTP Method

  • OPTIONS를 메소드에 입력하여 테스트 가능. 기본적으로 GET, POST, HEAD, OPTION을 제외히고 비활성확가 권고된다.
  • TRACE 사용 시 루프백 메세지로 쿠키 및 세션값이 서버에서 전송된다.

✔️ Request Method(ex. URL)

✔️ Protocol Version

 

(2) Request Header

  • Host: 서버의 도메인 주소
  • Connection: Keep-alive가 디폴트이며 HTTP/2에서는 없어짐
  • User-Agent: 사용자의 웹 브라우저 종류 & 버전 정보
  • Accept
    • Accept: 브라우저가 처리할 수 있는 데이터의 형태
    • Accept-Charset: 브라우저가 처리할 수 있는 문자 인코딩 방법
    • Accept-Language: 사용할 수 있는 언어
    • Accepr-Encoding: 브라우저가 처리할 수 있는 컨텐츠 압축 방식
  • Referer: 이전 페이지 주소
  • Cookie
  • Entity Header
    • Content-Length: 메세지 본문 크기를 바이트 형태로 표시
    • Content-Type: 컨텐츠 타입과 문자열 인코딩 등을 명시
    • Content-Language: 사용하는 언어
    • Content-Encoding: 컨텐츠 압축 방식

(3) Request Message Body

 

 

2.4 HTTP 보안

(1) CSP(CSP 노션 정리 링크 참고)

 

(2)HSTS(HTTP Strict-Transport-Security)

HTTPS를 통해서만 사이트에 엑세스해야하며 HTTP를 사용하는 시도는 브라우저에게 HTTPS로 변환되어야함을 알린다.

 

(3) HTTP 인증서

(3-1) SSL 인증서 발급

HTTPS도 SSL 프로토콜 위에서 동작하는 것과 같다. 네스케이프에 의해 SSL이 발명되고 IETF의 관리로 TLS라는 이름으로 바뀌었다. TLS 1.0은 SSL 3.0을 계승한다. HTTP이 SSL(TLS) 위에서 동작하는 것을 HTTPS이라고 한다.

 

SSL의 동작방식은 실 데이터를 대칭키로 암호화하고 대칭키의 키를 공개키로 암호화한다. 인증서는 아래와 같이 사이트 URL 왼쪽 자물쇠 모양을 확인해 조회할 수 있다.

 

 

 

서버에서 인증서를 발급받는 과정은 다음과 같다.

  1. 서버의 공개키와 비밀키를 생성.
  2. 인증서를 받급받기 위해 CA에 서버의 공개키와 서버의 각종 정보를 전달한다.
  3. CA는 서버로부터 받은 정보를 담아 SSL인증서를 발급한다.
  4. 3번에서 만든 인증서를 암호화하기 위해 CA의 공개키, 비밀키를 생성한다. CA의 비밀키로 SSL 인증서를 암호화한다.
  5. 암호화된 SSL인증서를 다시 서버에 전달한다.

 

☑️ 인증서 서명이 검증되었다.

= 인증서는 CA에 의해 서명된 진본이다.

= 인증서를 보낸 서버는 신뢰가능하다.

= 인증서에 포함된 공개키는 서버 것이다.

 

*CA는 디지털 서명을 이용한 전자상거래 등에 있어 누구나 객관적으로 신뢰할 수 있는 제3자를 의미함. 본인이라는 것을 증명하고 디지털 서명을 했을 시 해당 디지털 서명을 보증함.

*Root CA: CA 중에서 무조건 신뢰할 수 있는 기관을 최상위 인증기관이라 명명해 Root CA라고 부른다.

*SSC(Self Singed Cerficate)

: 공식적인 발급 기관 이외에 Root CA의 개인키로 스스로의 인증서에 서명해 최상위 인증기관 인증서를 만드는 것을 의미.

⇒ 우리가 만드는 Burp suite 인증서는 **프록시 인증서(SSC)**이다.

 

 

(3-2) SSL handshake

목적: 주고받을 데이터 암호화 알고리즘의 결정, 주고받을 암호화를 위한 대칭키를 얻음.

 

 

1) Client Hello(Client → Server)

  • 클라이언트 측에서 생성한 랜덤 데이터, 클라이언트가 지원하는 암호화 방식등, 세션 아이디다. 아래의 사진은 지원 암호화 방식 목록.

 

 

2) Server Hello(Server → Client)

  • 서버 측에서 생성한 랜덤 데이터 전송, 서버가 선택한 클라이언트의 암호화 방식.

 

 

3) Server Hello Done, Certificate 전달(Server → Client)

  • 인증서(Server의 SSL인증서): 서버의 인증서가 CA에 의해서 발급한 것인지 확인하기 위해 클라이언트 내장 CA를 확인한다. 인증서가 없다면 경고 메세지를 출력한다.
  • 인증서 내부에 공개키가 없다면 서버가 직접 전달한다.

 

 

4) Client Certificate Check

  • SSL 인증서를 발급한 CA는 비밀키로 인증서를 암호화했기 때문에 CA의 공개키로만 복호화가 가능하다. 즉 CA 공개키로 올바르게 복호화되었다는 것은 검증된 CA 발급 인증서라는 의미이다.
  • 보통 안드로이드나 브라우저의 경우 인증서를 발급하는 주요 인증기관(CA)의 리스트와 공개키를 가지고 있다. 없을 경우 외부 인터넷을 통해 확보하기 때문에 SSL 인증서 사용시 네트워크 연결이 필요하다.

 

 

5) Client Key Exchange, Change Ciper Spec(Client → Server)

  • CA로 인해 서버 검증을 마친 후 데이터를 안전하게 주고받기 위한 데이터 암호화를 진행한다. 클라이언트는 데이터를 암호화하기위한 비밀키를 생성한다.
  • 이 때의 비밀키는 1,2 번에 생성되었던 랜덤데이터를 조합해 pre master secret이라는 키를 생성한다.
  • 클라이언트는 이 비밀키를 보안하기 위해서 서버의 공개키로 암호화해서 서버에 전달한다. 서버의 공개키는 복호화한 인증서 내부나, 서버에게 직접 전달받아 얻을 수 있다.

 

 

6) Client / Server Handshake Finished, Change Ciper Spec(Server)

  • 서버는 전달받은 비밀키를 서버의 비밀키로 복호화해서 얻는다.
  • 통신 준비를 완료한다.
  • Alert는 통신 중 문제가 생기면 서로에게 메세지를 전송한다.

 

 

(3-3) TLS

SSL은 Netscape에 의해서 90년도에 개발되었다. SSL 초기버전인 1.0은 취약점으로 인해 미출시 되었고 이후 표준화 단계에서 IETF에 의해 TLS로 명칭이 바뀌었다.

SSL 2.0 1995

SSL 3.0   1996  
TLS 1.0 RFC 2246 1999  
TLS 1.1 RFC 4346 2006  
TLS 1.2 RFC 5246 2008  
TLS 1.3 RFC 8446 2018 다섯개 암호화 알고리즘으로 제한
-TLS_AES_128_GCM_SHA256      
-TLS_AES_256_GCM_SHA384      
-TLS_CHACHA20_POLY1305_SHA256      
-TLS_AES_128_CCM_SHA256      
-TLS_AES_128_CCM_8_SHA256      

 

 

 

(4) SSL 피닝

SSL Pinning은 클라이언트 측에서 사용하는 기법으로, SSL 핸드셰이킹 이후에도 서버의 증명서를 다시 확인하여 중간자 공격을 피할 수 있다. SSL 피닝 시 미리 저장된 증명서가 만료되거나 서버측에서 새로운 증명서로 연결을 시도하는 경우 신뢰할 수 없는 연결로 끊긴 후 앱이 벽돌이 되기 때문에 릴리즈 이전 pinning이 필요하다. SSL Pinning은 완전한 증명서 저장이나 해쉬된 공개키를 저장해 사용한다.

 

 

(5) 기타

아래의 도구들로 검사가 가능하다.

 

 

1) ssllabs

https://www.ssllabs.com/ssltest/

 

SSL Server Test (Powered by Qualys SSL Labs)

SSL Server Test This free online service performs a deep analysis of the configuration of any SSL web server on the public Internet. Please note that the information you submit here is used only to provide you the service. We don't use the domain names or

www.ssllabs.com

 

 

2) sslyze

https://github.com/nabla-c0d3/sslyze

 

GitHub - nabla-c0d3/sslyze: Fast and powerful SSL/TLS scanning library.

Fast and powerful SSL/TLS scanning library. Contribute to nabla-c0d3/sslyze development by creating an account on GitHub.

github.com

 

 

3) Openssl

가끔 ssllab이 안먹는 사이트는 openssl로 수행해줘야하는데 아래의 명령어로 HTTPS 프로토콜을 조회할 수 있다.

C:\Users> openssl s_client -ssl3 -connect [target_host:port]

C:\Users> openssl s_client -ssl3 -connect secureroot.co.kr:443

 

참조

https://gngsn.tistory.com/99

RFC 9110: HTTP 의미 체계 (rfc-editor.org)

HTTP 캐싱 - HTTP | 증권 시세 표시기 (mozilla.org)

HTTP 응답코드 메소드 정리 GET, POST, PUT, PATCH, DELETE, TRACE, OPTIONS (tistory.com)

HTTPS와 SSL 인증서 - 생활코딩 (opentutorials.org)

https://net-gate.tistory.com/36

https://baek9.github.io/2019/04/https의-원리-그리고-self-signed-ssl-까지/

 

 

'Web hacking > 개념 정리 & 심화' 카테고리의 다른 글

3) 게시판 개발 및 SQLi, XSS 취약점 테스트  (0) 2023.01.16
웹 서비스의 구조  (0) 2023.01.13
Django를 이용한 SSTI 실습  (0) 2022.12.01
Django 설치 및 실습 - 2  (0) 2022.12.01
Django 설치 및 실습 - 1  (1) 2022.11.17

관련글

티스토리툴바