HTTP 학습노트 2_HTTPS

일.HTTP

HTTPS 의 등장은 HTTP 의 단점을 보완하기 위함입니다:

1. 통신 내용이 도청될 수 있음

HTTP 는 평문 통신 (암호화하지 않음) 을 사용하므로, 내용은 매우 쉽게 도청당하며, HTTP 자체에는 암호화 기능이 없어 통신 내용을 암호화할 수 없습니다

암호화하지 않는 것은 본래 큰 문제가 아니었지만, TCP/IP 의 작동 메커니즘으로 인해 통신 회선상의 임의 노드가 보문을 얻을 수 있고, Internet 상의 임의 노드가 중계소가 될 수 있으므로, 암호화가 중요해졌습니다

암호화는 도청을 막을 수 없습니다. 도청자는 (암호화된) 보문을 쉽게 가져갈 수 있지만, 암호화는 보문의 가치를 잃게 할 수 있습니다 (일정 시간 내에 도청자가 복호화하지 못하도록 보장하면 됩니다)

2. 신원이 위장될 수 있음

HTTP 프로토콜에는 신원 검증 메커니즘이 없어, 통신 쌍방을 확인하지 않으므로, "가짜 클라이언트", "가짜 서버"가 존재할 수 있습니다. 또한, DoS(Denial of Service) 공격이 존재하는 것도 HTTP 에 신원 인증 메커니즘이 없기 때문입니다

신뢰할 수 있는 제 3 자 기관이 제공하는 디지털 인증서로 해결 가능합니다. 인증서는 서버가 "진짜 서버"임을 나타내는 데에도, 클라이언트가 "진짜 클라이언트"임을 나타내는 데에도 사용될 수 있으며, 각각이 각자의 인증서를 보유하면 됩니다

인증서는 매우 유용하지만, 보급되지 않은 이유는 제 3 자 기관이 제공하는*인증서는 유료 (장당 수천에서 십수만 RMB不等)*이기 때문입니다. 서버 측은 1 장이면 되지만, 방대한 클라이언트 인증서는 매우 비싸서, 일반 애플리케이션은 감당할 수 없어, 인터넷 뱅킹과 같은 애플리케이션만 클라이언트 인증서 설치가 필요합니다

P.S. 인증서가 무엇인지, 구체적 작동 메커니즘은 무엇인지에 대해서는 아래에서 자세히 설명할 것이며, 또한 제 3 자에 의존하지 않는 "자체 서명"도 있으며, 장기적으로 보면 매우 합리적이지만, 일반 기업도 감당하기 어렵습니다

3. 통신 내용이 변조될 수 있음

HTTP 는 보문의 완전성을 증명할 수 없어, 보문이 도중에 차단되어 변조되었는지 확인할 수 없으므로, MITM(Man-in-the-Middle, 중간자) 공격이 존재합니다

기존 변조 방지 방법에는 MD5, SHA-1 등의 해시값校验 및 PGP(Pretty Good Privacy, 완벽한 프라이버시) 를 사용한 파일의 디지털 서명 등이 있지만, 모두 사용하기 어렵습니다. 클라이언트 사용자가 직접 변조 발생 여부를 확인해야 하고, 브라우저가 자동으로 완료할 수 없어 매우 불편하기 때문입니다. 게다가, 이렇게 해도 통신 내용 변조를 100% 피할 수 없습니다. PGP 와 MD5 자체가 재작성될 수 있기 때문입니다

이.디지털 인증서와 하이브리드 암호화

###1.하이브리드 암호화

HTTPS 를 이해하기 전에 먼저 디지털 인증서가 무엇인지 이해해야 하며, 그 전에 3 가지 암호화 방식을 알아야 합니다:

• 대칭 암호화 (공유 키 암호화): 가장 간단한 암호화 방식으로, 통신 쌍방이 동일한 키를 보유

송신 측이 키로 암호화하여 암호문을 수신 측에 전송하면, 수신 측은 암호문을 받은 ��� 동일한 키로 복호화하여 평문을 얻습니다. 반대도 마찬가지입니다

단점: 키를 안전하게 상대방에게 전달할 수 없음 (네트워크 통신에서, 정보의 안전성은 암호화를 통해서만 보장할 수 있으며, 키를 안전하게 전달할 수 있다면 다른 정보도 안전하게 전달할 수 있음을 의미합니다)

• 비대칭 암호화 (공개 키 암호화): 키는 쌍으로 사용되며, 공개 키와 개인 키로 나뉩니다 (공개 키는 공개되고, 개인 키는 공개되지 않음)

공개 키를 공개하고, 송신 측이 공개 키로 암호화하면, 수신 측은 암호문을 받은 후 개인 키로 복호화하여 평문을 얻습니다. 역방향 통신 시 송신 측은 개인 키로 암호화하고, 수신 측은 공개 키로 복호화하면 됩니다

단점: 대칭 암호화 방식에 비해, 비대칭 방식의 암호화 복호화 과정에는 더 큰 오버헤드가 있습니다 (암호문 + 공개 키로 개인 키를 추론할 수 없도록 보장하려면 복잡한 알고리즘의 지원이 필요합니다)

• 하이브리드 암호화 (이상 두 방식 종합): 비대칭 방식으로 공유 키를 전달하고, 대칭 방식으로 통신

대칭 방식은 오버헤드가 작고, 최대 문제는 키가 안전하게 전달되었음을 보장할 수 없는 것이지만, 비대칭 방식은 바로 키 공유 문제를 해결할 수 있으므로, 하이브리드 암호화가 탄생했습니다

먼저 비대칭 방식으로 공유 키를 전달하여, 키가 안전하게 전달되었음을 보장한 후, 대칭 암호화 방식으로 통신하여, 비대칭 방식으로 통신하는 오버헤드를 피합니다. 완벽합니다

HTTPS 가 채택하는 것이 바로 하이브리드 암호화 방식입니다

###2.디지털 인증서

디지털 인증서는 실제로 암호화된 공개 키이며, 이 인증서는 인증서 소유자 (디지털 인증서 인증 기관) 와 공개 키 소유자 (서버/클라이언트) 의 신원을 동시에 증명할 수 있습니다. 구체적 원리는 다음과 같습니다:

배경: 서버 측 S 가 통신을 암호화하여, 고객의 온라인 업무 처리 시 정보 안전성을 보장하기로 결정

1. S 의 공개 키를 공개함 (클라이언트 C 에게 알림)

어떻게 공개할지가 문제입니다. C 가 공개 키를 받은 후 공개 키가 진짜인지 확인할 수 없기 때문입니다 (S 의 신원을 증명할 수 없음). 만약 다른 사람이 악의적으로 공개한 것이라면 곤란해집니다.

C 가 1 개의 가짜 공개 키만 받았다면, 해당 공개 키로 요청을 암호화한 후 S 가 복호화할 수 없어 요청을 거부하면 되고, 요청을 한 번 더 보내면 문제를 해결할 수 있습니다. 하지만 C 가 100 개의 가짜 공개 키를 받는다면? 계속 하나씩 검증할까요?

물론 안 됩니다. 이때 제 3 자 디지털 인증서 인증 기관의 도움이 필요합니다

2. S 가 디지털 인증서 인증 기관 CA 에게 공개 키 공개를 요청하여, 이 공개 키가 진짜임을 증명함 (S 의 신원 증명)

CA 는 S 가 준팁을 받은 후, 자신의 개인 키로 공개 키를 암호화하여, 얻은 이 암호문이디지털 인증서입니다. 그리고 이 인증서를 S 에게渡し, 앞으로 인증서만 C 에게 주면, C 는 당신이 진짜임을 안다고 합니다 (P.S. 실제로 "인증서"는 매우 적절합니다. S 는 자신의 신원을 증명하기 위해 CA 에 가서 신분증을 발급받고, CA 가 빨간 도장을 찍어주는 것이 바로 "인증서"입니다)

잠깐, 왜 C 는 인증서만 보면 진짜인지 아닌지 알까요?万一 인증서가 가짜라면? 인증서의 유효성을 어떻게 증명할까요?

이러한 끝없는 증명을 피하기 위해, 브라우저에는 CA 의 공개 키가 내장되어 있습니다. C 는 S 로부터 받은 인증서를 받으면, 바로 CA 의 공개 키를 꺼내 인증서를 복호화합니다. 인증서가 진짜라면, C 는 S 의 공개 키를 얻을 수 있습니다 (인증서는 CA 의 개인 키로 S 의 공개 키를 암호화한 산물로, 복호화하면 당연히 S 의 공개 키를 얻을 수 있습니다). 이는 S 의 신원을 증명할 뿐만 아니라, CA 의 신원도 증명합니다

주의, 브라우저 내장 CA 공개 키는무료입니다. 브라우저는 시장 수요에 적응하기 위해 주요 CA 의 공개 키를 브라우저에 내장해야 하며, CA 는 브라우저 공급자에게 팁을 줄 필요가 없습니다. 왜 계속 돈을 강조할까요?

인증서가 유료이고, 게다가 비싸다는 것을 설명하기 위해서입니다. 앞에서 언급했습니다:

>  인증서는 매우 유용하지만, 보급되지 않은 이유는 제 3 자 기관이 제공하는 인증서는 유료 (장당 수천에서 십수만 RMB不等) 이기 때문입니다. 서버 측은 1 장이면 되지만, 방대한 클라이언트 인증서는 매우 비싸서, 일반 애플리케이션은 감당할 수 없어, 인터넷 뱅킹과 같은 애플리케이션만 클라이언트 인증서 설치가 필요합니다

3. C 가 S 의 공개 키를 받은 후, 공유 키 (Pre-master secret 랜덤 비밀번호 문자열) 를 암호화하여 전송

4. S 는 받은 공유 키를 개인 키로 복호화하여, 공유 키를 얻은 후, 빠르고 안전한 통신 시작

위의 예는 서버 인증서로, 서버의 신원을 증명하는 데 사용됩니다. 마찬가지로, 클라이언트의 신원을 증명하는 데 사용되는클라이언트 인증서도 있습니다. 예를 들어 인터넷 뱅킹의 U 쉴드 등

인증서는 비싸기 때문에, 인터넷 뱅킹과 같은 것만 클라이언트 인증서가 있습니다

###3.자체 서명

유명한 CA 기관의 인증서는 비교적 비싸기 때문에, 일부 기업은 스스로 인증서를 만들기로 결정했습니다 (자신이 CA 가 됨). 이것이 때때로 웹 페이지를浏览할 때 브라우저가 창을 띄워 이 사이트의 인증서는 신뢰할 수 없지만, 계속 방문하시겠습니까...라고 표시하는 이유입니다. 실제로는 브라우저가 해당 사이트의 공개 키를 내장하지 않아서, 결과적으로 브라우저는 인증서를 보았지만, 인증서의 진위를 증명할 수 없습니다

따라서 자체 서명은 큰 의미가 없으며, 통신 안전성을 높일 수 없습니다. 자신이 CA 가 되어 유명한 CA 가 되고, 공개 키가 브라우저에 수집되어야 비로소 의미가 있습니다

자체 서명의 장점은 인증서가 저렴하다는 것으로, 생산 조건만 갖추면 무한히 많은 인증서를 생산할 수 있어, 마음대로 발행할 수 있습니다.

하지만 자신이 CA 가 되는 것은 그렇게 간단하지 않습니다. CA 는 매우 신뢰할 수 있는 안전 보호 조건을 갖춰야 하므로, 유명한 CA 가 인증서에 요금을 징수하는 것도 합리적이며, 인증서 발급 시스템의 안전을 유지하기 위함입니다

삼.HTTPS

###1.HTTPS 란 무엇인가?

HTTPS = HTTP + 암호화 + 인증 + 완전성 보호

      = HTTP + (SSL + TLS 로 구현된) 암호화 + (디지털 인증서로 구현된) 인증 + (디지털 인증서로 구현된) 완전성 보호
      
HTTP = TCP + IP

HTTPS = SSL + TCP + IP

P.S.TLS 는 SSL 을 원형으로 개발된 프로토콜로, 때로는 통일하여 SSL 이라고 부르므로, 마지막 등식에는 TLS 가 없습니다

주의:

1. HTTPS 는 HTTP 보다 2~100 배 느림

한편으로 SSL 통신 자체가 느리고 (SSL 의 전송 처리), 다른 한편으로 SSL 오버헤드가 크고, 처리 속도가 느림

근본적인 해결 방법은 없으며, SSL 가속기와 같은 (전용 서버) 하드웨어를 사용하여 SSL 처리 속도를 높일 수 있���

2. HTTPS 가 항상 암호화 통신을 하는 것은 아님

민감한 정보를 전송할 때만 암호화 (HTTPS 사용) 하고, 다른 때는 여전히 HTTP 를 사용하여, 통신 속도를 높이고 오버헤드를 줄일 수 있음

###2.암호화 방식

• 통신의 암호화

HTTP 에는 암호화 메커니즘이 없어, SSL(Secure Sockets Layer) 과 TLS(Transport Layer Security) 를 도입하여 통신의 암호화 구현

SSL 로 안전 통신 회선을 확립한 후, 이 회선에서 HTTP 통신을 하는 방식을 HTTPS(HTTP Secure, 하이퍼텍스트 전송 안전 프로토콜) 또는 HTTP over SSL 이라고 함

• 내용의 암호화

보문 본문을 암호화합니다. 물론, 이는 클라이언트, 서버의 쌍방향 협력 (모두 암호화/복호화 기능 지원 필요) 이 필요합니다

게다가 내용만 암호화하는 것은 안전하지 않습니다. 보문 수부가 암호화되지 않았기 때문에, HTTP 수부 주입 공격으로 뚫릴 수 있습니다

###3.신원 인증 방식

• BASIC 인증

서버 측이 401 응답을 반환하여 신원 인증을 요구하면, 클라이언트는 사용자 이름과 비밀번호를 Base64 인코딩하여 서버 측에 전송하고, 서버 측은 이 문자열에 따라 신원 검증을 수행하여, 성공하면 200 반환, 그렇지 않으면 계속 401

Base64 인코딩은 암호화가 아니며, 평문 전송과 차이가 없어, HTTP 전송은 매우 안전하지 않아, 자주 사용되지 않음

• DIGEST 인증

BASIC 인증이 Base64 인코딩으로 비밀번호를 전송하는 것이 안전하지 않다면, 비밀번호를 간단히 암호화합니다 (비밀번호에 MD5 연산 수행)

도청은 방지할 수 있지만, 신원 위장은 방지할 수 없어, 자주 사용되지 않음

• SSL 클라이언트 인증

인증서를 사용하면 신원 위장을 방지할 수 있습니다. 클라이언트가 클라이언트 인증서를 서버 측에 전송하면, 서버 측은 클라이언트의 공개 키를 꺼낸 후, HTTPS 통신 시작

하지만 클라이언트 인증서도 유료이므로, 자주 사용되지 않음

• 폼 기반 인증

가장 일반적인 것은 폼 기반 인증으로, 안전성은 Web 애플리케이션에 달려 있음

일반적으로 MD5 + salt(소금을 더한 MD5) 를 사용하며, 여기서 설명할 필요가 있습니다:

salt 는 실제로 서버 측이 생성한 랜덤 문자열로, 서버 데이터베이스에 저장됨

신규 사용자 등록 시 사용자 ID 에 대응하는 salt 문자열을 생성한 후, salt 문자열과 사용자의 평문 비밀번호를 결합하고, 결합 결과에 MD5 를 수행하여, 결과를 사용자 테이블 내 해당 사용자의 비밀번호 문자열로 함

로그인 시 테이블을 조회하여 사용자에 대응하는 salt 를 꺼내고, 평문 비밀번호 문자열과 결합하여 비밀번호 문자열을 얻은 후, 다시 사용자 테이블을 조회하여 해당 사용자의 비밀번호를 꺼내 비교하여, 신원 검증

소금을 더하는 것은 실제로 테이블 조회로 MD5 를破解하는 것을 방지하기 위함이며, 소금을 더하지 않은 MD5 는 레인보우 테이블로 빠르게 테이블 조회破解할 수 있고, 소금을 더한 후 비밀번호 특징을 줄입니다 (사용자 테이블 내 평문 비밀번호가 같은 사용자의 비밀번호 문자열이 다름)

MD5 + salt 에 대해 매우 좋은 글이 있습니다. 烏雲：소금 hash 로 비밀번호를 저장하는 올바른 방법 을 참조하십시오

사.HTTPS 통신 과정

1. 클라이언트가 Client Hello 보문을 전송하여 SSL 통신 시작

보문에는 클라이언트가 지원하는 SSL 의 지정 버전, 암호화 컴포넌트 (Cipher Suite) 리스트 (지원하는 암호화 알고리즘 및 키 길이 등) 가 포함됨

2. 서버 측이 SSL 통신 가능할 때, Server Hello 보문으로 응답

클라이언트와 마찬가지로, 보문에는 SSL 버전 및 암호화 컴포넌트가 포함됨. 서버 측의 암호화 컴포넌트 내용은 받은 클라이언트 암호화 컴포넌트에서 선별된 것임

3. 서버 측이 Certificate 보문 전송

보문에는 공개 키 인증서가 포함됨

4. 서버 측이 Server Hello Done 보문을 전송하여 클라이언트에 알림

초기 단계의 SSL 핸드셰이크 네고시에이션 부분 종료

5. SSL 첫 번째 핸드셰이크 종료 후, 클라이언트가 Client Key Exchange 보문으로 응답

보문에는 통신 암호화에 사용되는 Pre-master secret 이라는 랜덤 비밀번호 문자열이 포함됨. 이 보문은 단계 3 의 공개 키로 암호화됨

6. 클라이언트가 계속 Change Cipher Spec 보문 전송

이 보문은 서버 측에, 이 보문 이후의 통신은 Pre-master secret 키로 암호화될 것임을 알림

7. 클라이언트가 Finished 보문 전송

이 보문에는 연결부터 지금까지의 전체 보문의 종합校验값이 포함되며, 이번 핸드셰이크 네고시에이션이 성공할 수 있는지 여부는, 서버 측이 이 보문을 올바르게 복호화할 수 있는지 여부를 판정 기준으로 함

8. 서버 측도 마찬가지로 Change Cipher Spec 보문 전송

9. 서버 측도 마찬가지로 Finished 보문 전송

10. 서버 측과 클라이언트의 Finished 보문 교환 완료 후, SSL 연결 확립 완료

물론, 통신은 SSL 보호를 받으며, 이 지점부터 애플리케이션 계층 프로토콜의 통신, 즉 HTTP 요청 전송

11. 애플리케이션 계층 프로토콜 통신

HTTP 요청/응답 전송, MAC(Message Authentication Code) 보문 요약 추가, MAC 검사로 보문이 변조되었는지 알 수 있어, 보문의 완전성 보호

12. 마지막으로 클라이언트가 연결 끊음

close_notify 보문 전송

13. TCP 연결 끊음

TCP FIN 보문 전송하여 TCP 통신 종료

참고 자료

• 《図解 HTTP》