[네트워크] HTTPS에 대해 설명해주세요.

HTTP VS HTTPS

HTTP → 데이터를 주고 받기 위한 프로토콜 80번 포트 사용

암호화가 되지 않은 평문 데이터를 전송하는 프로토콜이다.

HTTP의 구조

HTTPS → 데이터 암호화가 추가된 프로토콜 443번 포트 사용

암호화 알고리즘

메시지 다이제스트

• 메시지 무결성 검사를 위해 암호 해시 함수를 이용해 생성하는 크기가 고정된 값
• 비 예측성 - 조금만 달라져도 예측할 수 없다.
• 역상 저항성
• 충돌 저항성
• MD5, SHA-256

대칭키 암호

• 대칭 키 암호 - 비밀 키라고도 한다.
• 암호화, 복호화에 같은 키를 사용하는 암호
• AES128, AES256-GCM(32byte)

공개키 암호

• 비대칭 키를 사용
• 개인키와 공개키가 있어 개인키로 공개 키를 유도
• 공개 키로 암호화, 개인 키로 복호화한다.
• 암복호의 비용이 대칭키에 비해 크다.
• 디피 헬만, RSA

전자 서명

• 공개 키 암호화 방식을 이용한 서명
• 개인 키로 서명, 공개 키로 검증한다.
• A는 원본 파일의 메시지 다이제스트를 구한다. MD 값을 서명하여 수신자에게 원본과 서명을 보낸다.
• 수신자는 송신자의 공개 키로 원본 파일과 서명을 검증한다.
• RSA, ECDSA

 

HTTPS는 대칭 키 암호화 채널을 사용한다. 그런데 여기서 문제가 있다. 대칭 키 암호를 어떻게 공유할 것인지에 대한 문제이다. 공개키 암호화 방식으로 대칭키를 공유하도록 하자.

 

대칭 키 공유 알고리즘

1. 사용자가 서버에게 공개키를 요청한다
2. 서버는 서버의 공개키를 보낸다.
3. 사용자가 공개키로 암호화한 대칭키를 생성하고 서버에게 보낸다.
4. 서버는 암호화된 대칭키를 자신의 공개키의 비밀키로 복호화해 대칭키를 얻는다.

그런데 서버가 보낸 공개키가 맞는지 확인할 방법이 없다. 누군가 장난을 쳤을 수 있다.

예를 들면 중간자 공격같은 해킹법이다.

공격자가 서버의 공개키 가로채고 자신의 공개키로 바꾸는 것이다. 따라서 공개키의 진위 여부를 판단할 수 있는 중개 기관이 필요했다.

인증서와 인증 기관이라는 용어가 등장한다.

인증서란?

다음 정보들의 조합으로 인증 기관이 자신의 개인키로 서명한 값이다.

• 서버의 공개 키
• 도메인 이름같은 서버 정보

인증 기관(CA)

인증서를 발행하는 기관으로 상업적인 기관이다.

CA는 서버가 제출한 서류를 심사하고 개인키로 서명한 값을 추가한 인증서를 생성해 서버에 준다. 이때 비용이 발생한다.

운영체제와 브라우저는 CA의 공개키를 미리 가지고 있어 따로 받지 않아도 된다.

인증서가 포함된 키 교환 과정

1. A→B 공개키 요청한다. B는 공개키가 들어있는 인증 기관의 인증서를 보낸다.
2. A는 인증기관의 인증서를 자신의 인증서 공개키로 검증한다.
3. 검증이 되면 A는 대칭키를 생성하고 인증서 안의 B 공개키로 암호화하여 전송한다.
4. B는 A가 보낸 암호화된 대칭키를 자신의 비밀키로 복호화해 대칭키를 얻도록 한다.

TLS란

Transport Layer Security의 줄임말로 HTTPS의 암호화를 담당한다.

SSL라고 불렸고 진화 버전이다.

1995년 넷스케이프에서 SSL을 개발해 3.0까지 나왔으며 1999년 TLS 1.0이 나오며 시작되었다. 현재는 1.3 버전까지 나왔다.

두 가지 프로토콜로 암호화를 한다.

레코드 프로토콜 - 전송 자료 형식 결정, 암호화가 이뤄진다.

핸드쉐이크 프로토콜 - 자료 전송 방법, 키 교환 합의 프로토콜

프로토콜 과정

1. 클라이언트에서 클라이언트의 지원 암호 방식, 세션 아이디 등 필요한 정보를 패킷에 담아 전송
2. 서버가 클라이언트 정보를 받아 암호화 방식을 선택하고 패킷을 전송한다. SSL 인증서를 세션키로 암호화한 패킷을 클라이언트에게 전송한다. 서버 공개키를 가진 패킷을 클라이언트에게 전송한다.
3. 클라이언트의 공개키를 가진 패킷을 서버에게 전송한다.
4. 세선키를 대칭키로 사용할 것을 정의해 클라이언트로 전송한다.