본문 바로가기
개발(Development)/Etc(기타)

HTTPS, SSL 인증서: 아주 쉽고 간단하면서도, 매우 상세한 정리.

by 카레유 2021. 1. 10.

HTTPS, SSL 인증서: 쉬운! 간단한! 상세한! 정리.

 

HTTPS 한줄 정리

공인된 '인증 기관'에게 내 서버의 '주민등록증'(SSL인증서)을 발급받고, '브라우저'와 통신할 때마다 제시하며 "나 인증받은 서버야." 라고 알리는 방식(HTTPS)이다.



HTTPS 세줄 정리

  1. 인증서 발급: 공인된 '인증 기관'에게 내 서버의 '주민등록증'(인증서)을 발급받는다.
  2. 서버 인증: '브라우저'가 내 서버에 접속할 때마다, 인증서를 제시하며 "나 인증받은 서버야. 안전해!" 라고 알린다.
  3. 암호화 통신: '인증서'에 적힌 내 서버의 '주민번호'(key)로 데이터를 암호화하여 주고 받는다



이제부터는 HTTPS/SSL 관련 용어, 암호화 기법, 상세한 원리를 정리한다.



관련 용어

  1. HTTP(Hypertext Transfer Protocol): HTML을 전송하기 위한 통신 규칙(규약)
    • 통신규약: 데이터의 첫번째 줄에는 '목차' 내용을 쓰고, 두번째 줄부터 '실제 내용'를 써서 주고 받겠다는 규칙 같은 것.
    • Hypertext: 링크로 연결되는 텍스트
    • HTML: Hypertext로 만들어진 문서(양식)
    • http://도메인주소 의 의미는 '주소'에 있는 컴퓨터와 http 방식으로 통신을 하겠다는 의미이다.
  2. HTTPS(HTTP Over 'Secure Socket Layer'): SSL 방식을 사용하는 HTTP
    • SSL을 적용하여 보안을 강화한 HTTP라고 볼 수 있다.
  3. SSL(=TLS)
    • SSL인증서를 통해 서버의 신원을 확인하고, 데이터를 암호화하여 통신하는 보안 방식
    • 넷스케이프에서 SSL을 만들었고, 나중에 표준화기구(IETF)로 이관되면서 TLS로 이름이 변경되었다.
  4. SSL 인증서
    • SSL방식에 사용하는 전자화된 문서로, 공인된 인증기관(Certificate Authority)에서 발급한다.
  5. CA(Certificate Authority)
    • SSL인증서를 발급하는 공인된 민간기업들
    • CA로 유명한 회사로는 Comodo, GoDaddy, Let's Encrypt(무료) 등이 있다.
    • 각 브라우저(크롬, 사파리 등)들은 공인 CA들의 목록을 내부에 저장하고 있다.



암호화 방식

: SSL에서는 아래의 2가지 암호화 기법을 적절히 혼용하여 사용한다.

  1. 대칭키 방식: 1개의 key 사용

    • 방식: 암호화하고 복호화 하는데 동일한 비밀번호(key)를 사용
    • 단점: 서버와 브라우저가 동일한 key를 사용하므로, 외부에 노출되면 보안에 취약해진다.
  2. 공개키 방식: 2개의 key 사용

    • key의 종류: 2개의 key를 만들어서 하나는 나(서버)만 갖고(비밀키:Private Key), 하나는 모두(브라우저)에게 나눠준다(공개키: Public Key)
    • 방식: '공개키'로 암호화한 건 '비밀키'로 복호화할 수 있고, '비밀키'로 암호화한 건 '공개키'로 복호화할 수 있다.
    1. 데이터 통신 활용
      • 예) 로그인: 브라우저에서 ID/PW를 공개키로 암호화해서 보내면, 서버는 비밀키로 복호화해서 로그인 처리한다.
    2. 인증 활용
      • 예) 전자서명: 서버가 비밀키로 암호화하여 보낸 데이터를, 브라우저가 공개키로 복호화할 수 있다면 서버가 비밀키의 주인임을 확인 수 있다.



HTTPS/SSL 기본 원리

: 대칭키 방식과 공개키 방식을 혼용하여 서버의 신원을 보증하고, 데이터 통신을 암호화 한다.

  1. 내 서버에서 '비밀키/공개키'를 생성한다.
  2. 공인기관(CA)에서 내 서버의 SSL인증서를 발급 받는다.
    • SSL인증서는 'CA의 비밀키'로 암호화 되어 있으며,
    • 인증서 내부에는 '내 서버의 공개키'가 저장되어 있다.
  3. 내 서버에 인증서를 저장하고, SSL 통신을 설정해둔다.
  4. 브라우저가 내 서버에 접속하면 인증서를 보내준다.
  5. 브라우저는 받은 인증서를 'CA의 공개키'로 복호화한다.
    • 인증서는 '발급한 CA의 비밀키'로 암호화 되어 있으며,
    • 브라우저(크롬, 사파리 등)은 '공인된 CA들의 공개키'를 내부에 보관하고 있다.
  6. 인증서 복호화에 성공한다면, 해당 인증서가 CA가 발급한 것임이 증명된다.
    • 인증서를 보낸 '내 서버'도 CA가 인증한 서버임이 증명된다.
  7. 복호화한 인증서에서 '내 서버의 공개키'를 취득하여 데이터 통신에 활용한다.
    • 서버와 주고 받는 데이터 자체는 '대칭키 방식'으로 암호화 하고,
    • '대칭키 방식에 사용된 key'를 '내 서버의 공개키'로 암호화 한다.



HTTPS/SSL 상세 과정

1. SSL 인증서 생성

  1. 내 서버의 비밀키/공개키 생성
  2. '서버 공개키'를 CA 전달하면서 'SSL인증서' 발급 요청
  3. CA는 'CA비밀키로 암호화된 인증서' 발급
    • CA의 정보(발급자)
    • 서버의 정보(도메인, 서버 공개키 등)

2. Handshake(악수): 클라이언트와 서버가 통신을 하기 위해 서로를 파악하는 과정

  1. 클라이언트(브라우저)가 서버에 접속: Client Hello라고 한다.
    • 클라이언트에서 생성한 '랜덤 데이터' 전송 to 서버
    • 클라이언트가 지원하는 '암호화 방식들' 전송 to 서버
    • 세션 아이디(식별자) 전송 to 서버
  2. 서버가 클라이언트에 응답: Server Hello라고 한다.
    • 서버에서 생성한 '랜덤 데이터' 전송 to 클라이언트
    • 서버가 선택한 '암호화 방식' 전송 to 클라이언트 (서로 암호화 방식을 맞추는 작업)
    • '인증서' 전송 to 클라이언트
  3. 클라이언트의 확인 작업
    • 서버에게 받은 인증서 확인: 브라우저에 내장된 CA리스트에 있는 CA의 인증서인지 확인
    • 인증서 복호화: 브라우저에 내장된 해당CA의 공개키로 복호화
      • 복호화 성공시, 인증서가 CA에 의해 발급된 것임이 증명됨
      • 인증서를 전송한 서버도 CA가 보증하는 서버임이 증명됨
    • 복호화된 인증서의 '서버 공개키' 획득
  4. 클라이언트의 'pre master secret key' 생성
    • pre master secret 키 생성 : '서버에게 받은 랜덤 데이터' + '클라이언트 생성 랜덤 데이터' 조합하여 특정값 생성
    • pre master secret 키 암호화: 인증서에 있는 '서버 공개키'로 암호화
    • '암호화된 pre master secret 키' 전송 to 서버
  5. 서버의 'session key'(대칭키의 key) 생성
    • '암호화된 pre master secret 키'를 받아서 '서버 비밀키'로 복호화
    • '복호화된 pre master secret 키'를 이용해 master secret 값 생성하고,
    • 최종적으로 session key라는 걸 생성하여 클라이언트와 공유
      • 클라이언트-서버는 데이터를 주고 받을 때, session key를 통해 '대칭키 방식'으로 암호화하여 통신한다.
  6. 핸드쉐이크 종료
    • 서버의 신원이 확인되었고,
    • 데이터 통신에 사용할 '대칭키 암호화 키값(session key)'도 공유하게 되었다.

3. 세션(전송): 실제로 서버와 클라이언트가 데이터를 주고 받는 단계

  1. 클라이언트의 데이터 암호화/전송
    • 'session key'를 통해 대칭키 방식으로 '데이터(ID/PW 등)를 암호화'하여 서버에 전송
  2. 서버의 데이터 복호화
    • 'session key'를 통해 대칭키 방식으로'데이터를 복호화' 하여 처리
    • 'session key'를 통해 대칭키 방식으로'응답 데이터(사용자 정보 등)를 암호화'하여 클라이언트에 전송
  3. 클라이언트의 데이터 복호화
    • 'session key'를 통해 대칭키 방식으로'데이터를 복호화' 하여 처리

4. 세션 종료

  1. 데이터 전송 종료
  2. SSL 통신 종료
  3. 'session key' 폐기
    • 매번 연결 시마다 새로운 session key를 생성하여 아주 짧은 시간만 사용하므로, 혹시 탈취되더라도 비교적 안전하다.



주체별 공개키/비밀키의 보유 정리

  1. CA(인증기관)
    • CA의 비밀키 보유
    • SSL인증서 암호화에 사용
  2. SSL인증서
    • 내 서버의 공개키 저장
    • 브라우저-서버 통신 데이터 암호화에 할용
  3. 브라우저:
    • 다양한 CA들의 공개키 보유
    • SSL 인증서 복호화에 사용
  4. 내 서버
    • 내 서버의 비밀키 보유
    • 브라우저-서버 통신 데이터 암호화에 할용

 

HTTPS/SSL 정리 완료!

 

댓글