학교에서 알려주지 않는 17가지 실무 개발 기술 16장

💡 필자가 책을 읽고, 몰랐던 부분이나, 특별히 메모할만한 내용을 추출하여 기록한 포스팅입니다. 책 내용 외에 추가 설명을 덧붙인 부분들이 있습니다.

---

[학교에서 알려주지 않는 17가지 실무 개발 기술] 구매하러 가기 ⬇

학교에서 알려주지 않는 17가지 실무 개발 기술:문자열 인코딩부터 웹 필수 지식까지

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."

---

이전 포스팅(⬇)에서 이어집니다.

[책장파먹기] RESTful: 학교에서 알려주지 않는 17가지 실무 개발 기술 15장

HTTPS, 그리고 TSL 과 SSL

SSL 은 Secure Socket Layer 의 약자로 ‘보안 소켓 계층’을 의미한다. 과거에는 SSL 을 보안 프로토콜로 활용하여 통신을 하였지만, 많은 취약점으로 더 이상 사용하지 않는다. HTTPS 는 TCP 대신 전송 계층 보안(TLS, Transport Layer Security) 프로토콜을 기반으로 하는 ‘안전한’ HTTP 통신이다. 오늘날, OpenSSL 과 같이 SSL 이라는 이름을 그대로 사용하는 라이브러리들도 있지만 이들이 사용하는 기술은 TSL 이라고 이해하면 된다.

안전하지 않은 HTTP

• HTTP 통신은 암호화되어있지 않아, 패킷이 탈취되는 경우 통신 내용이 그대로 드러난다. 가령, 사용자의 패스워드, 카드 정보와 비밀번호 등이 유출될 수 있다.
• HTTPS 는 통신되는 본문을 암호화하여, 패킷이 탈취되더라도 공격자가 해당 본문 내용을 식별할 수 없도록 한다.

HTTPS 동작 Layer

• HTTPS 는 4계층(전송) TLS 와 달리 더 높은 7계층(애플리케이션)에서 동작한다.
• 따라서, 7계층 정보인 HTTP 의 도메인 주소가 신뢰할 수 있는지 검사도 가능하다.
• 이 때 활용되는 것이 ‘인증서’인데, 신뢰할 수 있는 인증서 발급기관 목록은 https://www.checktls.com/showcas.html 에서 확인할 수 있다.

메시지 암호 키 교환

RSA 를 활용한 메시지 키 교환방식의 한계

RSA 방식 자체가 취약한 것은 아니지만, 이를 사용한 키 교환 방식에 취약점이 발견되어 TLS 1.3 부터는 지원하지 않는다. 서버와 통신하는 모든 클라이언트와의 키 교환이 공개키 하나에 의존하기 때문에, 비공개키가 한 번이라도 노출되면, 미래에 주고받게 되는 모든 메시지는 물론, 과거에 주고받았던 메시지도 모두 복호화하는 것이 가능해진다.

DHE, ECDHE

• DHE: 디피-헬먼 알고리즘
• ECDHE: DHE 의 취약점을 보완한 ‘타원 곡선 디피-헬먼 알고리즘’ Elliptic Curve Diffie-Hellman Ephemeral

위의 RSA 방식과 달리, 공개키 교환 후 추가 과정을 더해 키를 생성하기 때문에, 비밀키가 노출되더라도 과거에 주고받았던 메시지가 노출될 위험이 없다. 단, 미래에 주고받는 메시지는 복호화될 여지가 남아있다.

PFS - Perfect Forward Security

DHE 방식처럼 비밀키가 노출되어도 과거에 주고받은 메시지가 안전한 특성을 PFS 라고 한다.

반응형

인증서(X.509)

신뢰할 수 있는 인증기관(CA, certificate authority)에서 발급한다.

대표적인 인증기관(CA)으로 Comodo, GoDaddy, Symantec(인수 전 VeriSign) 이 있다. 대부분 미국과 유럽에 있다.

X.509 란 인증서를 위한 표준이다.

인증서를 구성하는 정보 (X.509 스펙)

• 발행기관
• 인증서 버전
• 고유번호
• 인증서 소유자 및 소유자 정보
• 등

인증서 발급시 주의점

인증서의 종류

• 싱글도메인: 도메인 1개를 지원
• 멀티도메인: 제한된 개수의 서브 도메인을 지원
• 와일드카드 도메인: 개수 제한이 없는 서브 도메인

실무에서는 대부분 와일드카드 도메인을 구매한다.

인증서 도메인 이름 최대허용 글자수

인증서 도메인 이름인 CN 은 최대 64글자까지 사용할 수 있다.

인증서 도메인 포함에 따른 연결

클라이언트는 반드시 인증서 발급대상의 도메인(CN)의 전체 또는 일부를 포함해야만 연결을 맺을 수 있다.

인증서를 사용하는 이유

암호 키 교환 과정에서 인증서를 사용하는데, 인증서를 사용하지 않으면, 중간자가 개입하여 메시지를 변조하는 등의 공격이 있을 수 있다. 즉, 클라이언트가 민감정보를 전송하고자 하는 서버가 믿을만한 서버인지 검증하기 위해 인증서를 활용한다.

인증서 서명

서명은 인증서에 포함된 여러 정보와 발급기관의 ‘비밀키’를 사용하여 만들어진다. 따라서, 인증서 정보가 변조되면 서명이 바뀌어 일치하지 않게 되므로, 클라이언트는 서명을 확인하는 것만으로 인증서를 보낸 서버가 신뢰할 수 있는지 확인할 수 있다.

인증서 신뢰체인 - Chain of trust

신뢰할 수 있는 인증기관(Root CA)에서 발급한 인증서를 발급받은 중간기관은 다시 인증서를 발급할 수 있다. 각 인증서는 서로 연결되어있고, 클라이언트는 이 연결정보를 통해서 인증서가 신뢰할 수 있음을 판단할 수 있다.

💡 보통은 중간기관이 1개이거나 중간기관이 없는 인증서들이 대부분이다. 하지만 이론상으로는 무수히 많은 중간기관이 있을 수 있다.

서버가 보내온 인증서 검증하기

클라이언트는 서버가 보내온 인증서는 신뢰할 수 있는 기관에서 발급한 것인지 어떻게 확인할 수 있을까? 서버가 보내온 인증서는 인증서를 발급한 기관의 정보를 갖고 있다. 발급기관의 인증서는 또 다른 발급기관이 발급한 인증서이다.

최상위 인증기관 → 중간 발급기관 A → 중간 발급기관 B → 서버

인증서의 발급기관을 따라가다보면 최상위 인증기관에 이르게 된다. 최상위 인증기관의 인증서는 공개키를 가지고 있으며, 이 공개키로 중간기관의 서명을 복호화한다. 그 결과 최상위 인증서의 해시값이 도출되고, 이를 최상위 인증서의 해시값과 비교하여 유효한 서명인지 확인한다.

 

인증된 중간기관(A)의 인증서 또한 공개키를 가지고 있고, 이를 통해 하위 발급기관(B)의 인증서의 서명을 복호화한다. 이렇게 복호화된 해시값이 중간기관 A 의 해시값과 일치하면 하위 발급기관(B) 의 인증서가 인증된다.

이렇게 연쇄적으로 서버의 인증서가 유효한지 검증할 수 있게 된다.

Https 핸드셰이킹

클라이언트(C) ↔ 서버(S)

1. (C→S) Client Hello: 클라이언트 랜덤값, 사용가능한 암호화 목록 등
2. (C←S) Server Hello: 서버 랜덤값, 서버 인증서(공개키 포함)
3. (C) 신뢰기관에서 발급한 것인지 인증서 검증
4. (C→S) Premaster 키 생성 후 이를 공개키로 암호화
   • RSA 인 경우 Premaster 키를 암호화하여 곧바로 서버로 전송
   • DHE, ECDHE 의 경우 주고받은 파라미터를 통해 Premaster 값을 계산
5. (S) 비밀키로 복호화하여 Premaster 키 획득
6. (C) 클라이언트 랜덤, 서버 랜덤, Premaster 키를 조합해 암호화 키(대칭키) 생성
7. (C→S) 검증 완료 및 암호화 통신 알림 메시지
8. (S) 클라이언트 랜덤, 서버 랜덤, Premaster 키를 조합해 암호화 키(대칭키) 생성
9. (C←S) 검증 완료 및 암호화 통신 알림 메시지
10. (C↔S) 6. 및 8. 에서 생성한 대칭키로 암호화하여 통신

---

[학교에서 알려주지 않는 17가지 실무 개발 기술] 구매하러 가기 ⬇

학교에서 알려주지 않는 17가지 실무 개발 기술:문자열 인코딩부터 웹 필수 지식까지

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."