[정리] HTTPS의 보안성 저리

shininghyunho·2021년 5월 27일
0

CS

목록 보기
3/8

HTTPS는 HTTP에 보안기능을 추가한 것이다(SSL)
SSL은 공개키로 비밀키로 대칭키를 서버와 주고받고
대칭키로 데이터를 안전하게 주고받음

HTTPS(Hyper Text Transfer Protocol Secure)

HTTP는 Hypertext인 HTML을 전송하기 위한 통신규약인데 여기에 보안성을 추가한것이 HTTPS이다. HTTPS는 소켓 통신에서 일반 텍스트를 이용하는 대신에, 웹 상에서 정보를 암호화는 SSL이나 TLS(SSL에서 발전한 버전) 프토로콜을 통해 세션 데이터를 암호화한다. 또한 HTTP는 포트 80번을 사용하지만 HTTPS는 443번 포트를 사용한다.

암호화 방식

HTTPS는 공개키 암호화 방식과 대칭키 암호화 방식을 사용한다.

  • 공개키 암호화
    공개키 암호화는 공개키, 비밀키 두개를 사용한다. 공개키는 상대방에게 전달하는 반면 비밀키는 오직 나만 갖고 있다.

    상대방이 데이터를 공개키로 암호화 해서 내게 전달해주면 나는 비밀키를 통해 풀 수있다.(상대방이 나만 열 수 있게 데이터를 보낼 수 있음.)

    반대로 내가 비밀키를 통해 암호화하고 상대방에게 보내면 상대방은 내 공개키를 통해 데이터를 확인할 수 있다.(내가 비밀키로 암호화 한것임을 상대방에게 알려 상대방에게 내가 보낸 데이터임을 알 수 있게 해줌.)

    	대신 공개키 암호화는 서버의 자원을 많이 사용해 지속적으로 쓰기는 힘들다.

    (그래서 서로의 존재를 확신시킬때 사용하거나 대칭키 전달을 위해 사용)

  • 대칭키 암호화
    공개키와는 다르게 대칭키는 암호화와 복호화가 동일한 방식으로 이루어진다.
    그래서 데이터를 주고 받을때는 서로 대칭키를 주고 받고
    대칭키로 암호화해서 데이터를 주고 받는다.
    (대칭키를 서로 전달할때는 공개키를 사용한다.)

쉽게 이야기해
공개키를 통해 대칭키를 전달하고
대칭키를 이용해 데이터를 주고받는다.

SSL 인증서

위에서 서로의 존재를 확신할때 공개키를 사용한다고 했는데 이 공개키에 들어가는게 SSL 인증서이다. 이 인증서는 CA(Certificate authority, 인증 기관)라는 제 3자가 발행해준다. CA는 엄격하게 공인된 기업들만 참여할수있다.

클라이언트가 서버로부터 SSL 인증서를 받는다.
먼저 해야할일은 브라우저에 저장된 CA리스트에서 인증서를 발급한 CA를 찾아본다.

확인이 된다면 CA에서 제공한 공개키를 이용해 암호화된 해시 값을 복호화해본다.
인증서가 복호화된다면 해당 서버의 내용물에 대한 해시값을 CA의 개인키를 통해 암호화한것이 확실하니 인증서를 신뢰할 수 있게된다.

alicek106님 블로그의 설명이다.

다음과같이 CA가 인증서의 해시값을 암호화해주고 그 암호화된 값을 인증서에 넣는다.

그리고 CA의 공개키로 암호화된 해시값을 복호화했을때 인증서에 들어있던 인증서 해시값과 비교해본다.

복호화된다면 클라이언트는 해당 서버를 신뢰할 수 있게된다.

그리고 Google CA도 더 상위 기관으로 부터 인증을 받았다.

Google CA는 최고 권위 CA(Root CA)인 Geotrust의 공개키를 활용해 위와 비슷한 방법으로 인증된 CA임을 인증한다. 이러한 원리를 Chain of Trust라고 한단다. 여기서 중간 CA 기관은 ICA라고 한다.

모두 Root CA로부터 인증을 받지 않고 중간에 ICA를 두는 이유는
인증을 수행하는 기관의 인증서가 손상되거나 비밀키가 유출될 경우 이를 철회(revoke) 할 수 있도록 하기 위함이란다. 이를 통해 더욱 보안체계를 강화한것이다.


SSL 통신과정

SSL 통신과정은 총 3가지로 이루어진다.

구체적으로보면 다음과 같다.


(HTTP는 TCP/IP 기반이니 3-way handshaking은 당연히 진행한다.)

핸드쉐이킹 단계만 보면

  1. clinet hello
    어떠한 암호화 방식을 사용할지에 대한 협상 단계이다.
    3가지 정보를 보낸다.

    • 클라이언트가 생성한 랜덤 데이터 : pre master key를 만들기 위함
    • 클라이언트가 지원하는 암호화 방식들
    • 세션 아이디 : 최종적으로 세션 아이디를 대칭키로 사용할건데 이미 SSL 핸드 쉐이킹을 했었다면 이를 건네주면 된다.
  2. server hello
    클라이언트에 대한 응답이다. 암호화 방식 협상을 채결하고 인증서를 보낸다.
    보내는 내용

    • 서버가 생성한 랜덤 데이터 : pre master key를 만들기 위함
    • 서버가 선택한 암호화 방식
    • ssl 인증서
  3. 서버의 인증서 확인 및 대칭키 생성
    인증서 확인 위에서 설명한 방법을 사용하고
    서로 주고 받은 랜덤 데이터를 조합해 pre master secret를 생성한다. 이는 뒤에서 대칭키로 활용할 세션키를 생성하는 재료이므로 노출되서는 안된다.
    그리고 이렇게 만든 pre master secret는 서버의 공개키로 암호화하여 전송한다.

  4. 대칭키 교환 완료
    서버의 비밀키로 전송받은 pre master secret를 복호화한다.

    이후 서로 pre master key를 master secret으로 만들고 이를 통해 session key를 만든다. 그리고 이 session 키를 데이터를 교환할 대칭키로 사용한다.

  5. 핸드쉐이킹 종료
    서로 핸드쉐이킹 종료 단계를 알린다.

참고

alicek106
오픈튜토리얼
12me

profile
shining itself

0개의 댓글