HTTP 완벽 가이드 (14)

 

 

https://drive.google.com/file/d/1htRSl0N5V7Lb6U51W_HmGzcbM7_1xRZz/view?usp=sharing

14장.drawio

 

14.1 HTTP를 안전하게 만들기

대량 구매, 은행 업무, 보안 자료 접근 등을 위해서는 HTTP와 디지털 암호 기술을 결합해야 한다.

• 효율적, 이식성이 좋고, 쉬운 관리, 현실 세계의 변화에 대한 적응력, 사회와 정부의 요구사항 만족
• 서버 인증 - 클라이언트는 자신이 위조된 서버가 아닌 진짜와 이야기 하고 있음을 보장받아야 함.
• 클라이언트 인증 - 서버는 자신이 진짜 사용자와 이야기하고 있음을 알 수 있어야 함.
• 무결성 - 데이터 위조 방지
• 암호화 - 도청 걱정 x
• 효율 - 저렴한 클라이언트나 서버도 이용할 수 있도록 충분히 빠른 알고리즘
• 편재성(Ubiquity) - 거의 모든 클라이언트와 서버에서 지원되는 프로토콜
• 관리상 확장성 - 누구든 어디서든 즉각적인 보안 통신 가능
• 적응성 - 현재 알려진 최선의 보안 방법 지원
• 사회적 생존성 - 사회의 문화적, 정치적 요구 만족

14.1.1 HTTPS

애플리케이션 계층과 전송 계층 사이에 보안 계층이 존재함.

• SSL(Secure Sockets Layer)
• TLS(Transport Layer Security)

어려운 인코딩, 디코딩 작업은 SSL 라이브러리 안에서 일어남 → 프로토콜 처리 로직을 크게 변경할 필요 없음

TCP 입력/출력 호출을 SSL 호출로 대체

14.2 디지털 암호학

대칭키 암호 체계

인코딩과 디코딩에 같은 키를 사용하는 알고리즘

• 기밀성 제공, 무결성/인증/부인방지 보장 x
• SEED, DES, AES, ARIA

비대칭키 암호 체계

인코딩과 디코딩에 다른 키를 사용

• 느리지만 키분배 필요 없음. → 기밀성/인증/부인방지 기능 제공

공개키 암호

비밀 메시지를 전달하는 수백만 대의 컴퓨터를 쉽게 만들 수 있는 시스템

디지털 서명

메시지가 위변조 되지 않았음을 입증하는 체크섬

디지털 인증서

신뢰할 만한 조직에 의해 서명되고 검증된 신원 확인 정보

암호

초기 알파벳 순서상 세 번 뒤의 글자로 교체하는 세글자 순환 암호 사용

code book → encoder/decoder

• 평문, 인코딩 함수, 디지털 인코딩 키가 주어지면 암호문 C를 생성하는 방식
• 디코딩 함수, 디코딩 키가 주어지면 도로 평문을 얻어낼 수 있음.

대칭키 방식의 단점

• 사용자 별로 키 관리 어려움.
  • 몇 천명의 사용자 → 몇 천개의 키
  • N개의 노드가 있을 때 상대 N-1과 대화를 나누려면 N^2 개의 비밀키가 필요함.

공개키 방식

• 공개적인 인코딩 키
• X에게 보내는 메시지를 같은 키로 인코딩할 수 있고, X가 개인 디코딩키로만 복호화 가능.
• → 메시지를 디코딩하는 능력은 소유자에게만 부여함.
• PKI(Public-Key Infrastructure) 표준화 작업

공개키 암호의 과제

• 공개키
• 가로채서 얻은 암호문의 일부
• 메시지와 그것을 암호화한 암호문 → 인코더에 임의의 텍스트를 넣고 실행해서 획득함.

위 3가지 내용을 공격자가 알고 있어도 비밀 개인키를 계산할 수 없음을 보장해야 함.

RSA 알고리즘

• 위의 조건을 모두 만족함.

현재는 혼성 암호 체계를 활용함.

• 안전한 의사소통 채널 수립 시 → 공개키 암호 사용
• 채널을 통해 대칭 키를 생성하고 교환, 나머지 데이터를 암호화할 때는 대칭키를 사용함.

TLS는 비대칭/공개 키 및 대칭 암호화를 모두 사용함.

• 세션 키 → 각 통신 세션마다 대칭 암호화를 위한 새로운 키 생성

 

디지털 서명

누가 메시지를 썼는지 알려주고 그 메시지가 위조되지 않았음을 증명하기 위한 서명

• 암호 체크섬(checksum)
• 송신 중인 메시지를 공격자가 수정하면 체크섬이 변경됨 → 위변조 확인
• 체크섬은 서명 저자의 비밀 개인 키와 관련되어 있기 때문에, 침입자는 위조된 메시지에 대한 올바른 체크섬을 날조해낼 수 없음.
• 개인 키 → 지문

 

노드 A에서 노드 B로 메시지를 보내고 서명하는 과정.

• 가변 길이 메시지 → 고정 길이 요약(digest) 생성 → 서명 함수 적용
• 이에 대한 역함수 E를 사용해서 요약을 얻고 B가 갖고 있는 버전의 요약과 일치한지 비교함.
  • 같지 않으면, 메시지가 송신 중에 위조되었거나 발송자가 노드 A의 개인키를 갖고 있지 않은 것

디지털 인증서

• 대상의 이름(사람, 서버, 조직 등)
• 유효 기간
• 인증서 발급자(누가 보증하는지)
• 인증서 발급자의 디지털 서명

X.509 v3 인증서

디지털 인증서에 대한 전 세계적 표준은 없음.

대부분 많이 따르는 구조는 X.509 v3 인증서.

X.509 인증 필드

 

서버 인증

 

HTTPS 트랜잭션 시작 시, 최신 브라우저는 서버에서 인증서를 갖고 옴. 서버가 인증서를 갖고 있지 않으면 보안 커넥션은 실패함.

서버 인증서의 필드

• 웹 사이트의 이름과 호스트 명
• 웹 사이트의 공개키
• 서명 기관의 이름
• 서명 기관의 서명

🔑 CA(Certificate Authority)

인증서를 발급해주는 기관. 자체적으로 공개키와 비밀키를 갖고 있음.

• Self-Signed : CA가 아닌 자신의 비밀키로 암호화해 서명 등록
• 사설 인증서를 사용할 경우 ‘신뢰할 수 없는 사이트입니다.’ 문구가 뜸.
• 신뢰할 수 있는 서명 기관의 공개키는 브라우저의 CA 리스트에 존재함. </aside>

HTTPS의 세부사항

HTTPS는 HTTP의 가장 유명한 보안 버전

<https://cajun-shop.securesites.com>

• 보안이 되는 HTTPS 스킴 접두사는 https

 

 

TLS Handshake

참고 블로그 : https://babbab2.tistory.com/7, https://brunch.co.kr/@sangjinkang/38

• 웹 서버의 443포트로 연결 → TCP 핸드셰이크를 통해 TCP 연결이 열린 이후에 TLS 핸드셰이크 시작
• 암호법 매개변수, 교환 키를 협상하면서 SSL 계층을 초기화한다.
• 이후에 요청 메시지를 보안 계층에 보낼 수 있고, TCP로 보내지기 전에 암호화된다.
• 터널링이 주목적
• 대칭키 교환

---

• 프로토콜 버전 번호 교환
• 양쪽이 알고 있는 암호 선택
• 양쪽의 신원을 인증
• 채널을 암호화하기 위한 임시 세션 키 생성

 

 

SSL은 상호 인증을 지원하지만, 보안 HTTPS 트랜잭션은 항상 서버 인증서를 요구. 클라이언트 인증서는 잘 쓰이지 않음.

사이트 인증서 검사

• 날짜 검사 : 유효기간 확인, 만료되거나 활성화되지 않았다면 에러
• 서명자 신뢰도 검사 : 알려져있지 않은 인증기관으로부터 서명받은 인증서를 받았다면, 브라우저가 경고함
• 서명 검사 : 서명기관의 공개키를 서명에 적용, 체크섬 검사
• 사이트 신원 검사 : 인증서의 도메인과 대화중인 서버의 도메인 이름이 같은지 비교

가상 호스팅과 인증서

하나의 서버에 여러 개의 호스트 명 → 도메인마다 모든 인증서를 발급받는 것이 비효율적임.

• 서버 인증서의 공식 호스트명과 사용자 브라우징 가상 호스트명이 맞지 않으면 경고 발생 → 리다이렉트
• Single-Domain SSL : 하나의 도메인에만 적용 가능
• WildCard SSL : 하나의 인증서로 서브 도메인 무제한 SSL 적용
• Multi-Domain SSL : 하나의 인증서로 여러 도메인(전혀 다른 도메인)

SNI(Server Name Indication)

• 서버는 클라이언트가 제공한 도메인 이름에 맞는 인증서 전송

진짜 HTTPS 클라이언트

SSL은 복잡한 바이너리 프로토콜. 상용, 오픈소스 라이브러리로 서버 프로그래밍을 쉽게 가능

OpenSSL

가장 인기 있는 SSL/TLS 오픈소스 구현.

• 302 Found
  • page rank 점수를 새로운 URL로 이동시키지 않음.
  • 쇼핑몰 제품이 일시 품절 or 기간한정 판매 종료 알리는 페이지 → 기존 사이트랭크를 유지하면서 일시적으로 사용자에게 알림 가능
  https://inpa.tistory.com/entry/HTTP-🌐-301-vs-302-상태-코드-차이점-💯-완벽-정리
  • 웹사이트를 HTTP에서 HTTPS로 전환하는 경우 → 301 사용
  • 302는 SEO 순위에 영향을 주지 않고 새 페이지로 임시로 옮길 필요성이 있을 때 사용함.
• A browser receiving this status will automatically request the resource at the URL in the Location header, redirecting the user to the new page. Search engines receiving this response will not attribute links to the original URL to the new resource, meaning no SEO value is transferred to the new URL.

프록시를 통한 보안 트래픽 터널링

프록시는 암호화된 요청을 다룰 수 없음 → HTTPS 터널링 프로토콜

**CONNECT** home.netscape.com:443 HTTP/1.0
User-agent: Mozilla/1.1N

<이후 SSL로 암호화된 데이터>

• 목적지 서버 연결에 성공하면 200 Connection established 응답을 클라이언트에게 보낸다.