보안 HTTP

1. HTTP를 안전하게 만들기

웹은 안전한 방식의 HTTP를 필요로 함.

• 서버 인증: 클라이언트는 자신이 위조된 서버가 아닌 진짜와 이야기하고 있음을 알 수 있어야 함
• 클라이언트 인증: 서버는 자신이 가짜가 아닌 진짜 사용자와 이야기하고 있음을 알 수 있어야 함
• 무결성: 클라이언트와 서버는 데이터가 위조되는 것으로부터 안전해야 함
• 암호화: 클라이언트와 서버는 도청에 대한 걱정 없이 서로 대화할 수 있어야 함
• 효율: 저렴한 클라이언트나 서버도 이용할 수 있고, 알고리즘은 충분히 빨라야 함
• 편재성: 프로토콜은 거의 모든 클라이언트와 서버에서 지원되어야 함
• 관리상 확장성: 누구든 어디서든 즉각적인 보안 통신을 할 수 있어야 함
• 적응성: 현재 알려진 최선의 보안 방법을 지원해야 함
• 사회적 생존성: 사회의 문화적, 정치적 요구를 만족시켜야 함

1. HTTPS란?

HTTP를 안전하게 만드는 방식 중 하나.

• 모든 HTTP 요청과 응답 데이터는 네트워크로 보내지기 전에 암호화 됨
• HTTPS는 HTTP의 하부에 전송 레벨 암호 보안계층을 제공함
• 보안계층은 SSL 또는 TLS를 이용하여 구현
• 어려운 인코딩, 디코딩 대부분은 SSL 라이브러리 안에서 일어남

2. 디지털 암호학

암호법은 메시지 인코딩과 디코딩에 대한 과학이자 기술. 단순 메시지를 암호화하는 것뿐 아니라, 메시지의 변조를 방지하기 위해 사용 할 수도 있음.

암호 용어

• 암호란? 메시지를 인코딩하는 어떤 특정한 방법과 나중에 그 비밀 메시지를 디코딩하는 방법. 암호법은 암호라 불리는 비밀 코드에 기반
• 평문 (Plaintext): 인코딩 되기 전의 원본 메시지
• 암호문 (Ciphertext): 암호가 적용되어 코딩된 메시지

암호 기계와 키

• 암호 기계란? 초기의 암호는 사람이 직접 인코딩하고 디코딩해야 해서 상대적으로 간단한 알고리즘으로 시작. 기술이 진보하면서, 보다 복잡한 암호를 만들기 위해 인코딩, 디코딩 하는 기계를 만들기 시작
• 키가 있는 암호: 누군가 기계를 훔치더라도 키가 없이는 디코더가 동작하지 않음. 이러한 암호 매개변수를 키라고 부름. 암호키는 하나의 암호기계를 여러 가상 암호기계의 집합으로 만들어 줌.

디지털 암호의 장점

• 속도 및 기능에 대한 기계장치의 한계에서 벗어남: 복잡한 암호화 알고리즘 가능
• 매우 큰 키를 지원하는 것이 가능해 짐: 많은 조합이 가능해지고 무작위 크래킹이 어려워짐

3. 대칭키 암호법

인코딩과 디코딩할 때 같은 키를 가지는 기법

발송자는 공유된 비밀 키로 메시지를 암호화하고, 수신자는 암호문을 평문으로 복원하기위해 비밀 키를 사용

 

키 길이와 열거 공격

무차별로 모든 키 값을 대입해보는 공격

40비트 키는 작고 중요하지 않은 업무에는 충분, 그러다 오늘날의 기술로는 쉽게 깨질 수 있음

128비트 대칭키 암호는 매우 강력한 것으로 간주

 

 

공유키 발급하기

대칭키 암호의 단점 중 하나는 발송자와 수신자가 서로 대화하려면 둘 다 공유키를 가져아 한다는 점

만약 N개의 노드가 있고, 각 노드가 상대 N-1과 대화를 나눠야한다면 N^2의 비밀키가 필요

 

4. 공개키 암호법

공개키 암호 방식은 두 개의 비대칭 키를 사용한다.

1. 호스트의 메시지 인코딩을 위함
2. 호스트의 메시지 디코딩을 위함

인코딩 키는 모두를 위해서 공개되어 있고, 호스트만이 개인 디코딩 키를 알고 있음.

즉, 모든 사람이 X에게 보내는 메시지를 같은 키로 인코딩 할 수 있지만, X를 제외한 누구도 그 메시지를 디코딩 할 수 없음. 이러한 공개키 암호화 기술은 보안 프로토콜을 전 세계의 모든 컴퓨터 사용자에게 적용하는 것을 가능하게 함.

 

RSA

공개키 비대칭 암호의 과제는 다른 사람이 내용을 알고 있다 해도 비밀인 개인키를 계산할 수 없도록 해야 함.

공개키, 평문의 일부, 공개키로 평문을 인코딩하여 얻은 평문에 대한 암호문, 그리고 RSA 구현의 소스코드까지 주어졌다 하더라도 암호를 크래킹하여 개인키를 찾아내는 것은 어려운 문제.

 

혼성 암호 체계와 세션 키

공개키 암호 방식의 알고리즘은 계산이 느린 경향이 있음.

 

5. 디지털 서명

인터넷 보안 인증서에서 중요한 기술로, 보통 비대칭 공개키에 의해 생성됨.

• 서명은 메시지를 작성한 저자가 누군지 알려줌
  • 저자는 개인 키를 가지고 있기 때문에 저자만이 체크섬을 계산 가능.
• 서명은 메시지 위조를 방지함
  • 만약 공격자가 송신 중인 메시지를 수정했다면, 체크섬은 더 이상 그 메시지와 맞지 않게 됨.

디지털 서명 생성 및 검증 과정

디지털 서명은 메시지의 무결성과 인증을 동시에 제공

1. 노드 A (서명 생성): 노드 A는 가변 길이 메시지를 정제하여 **고정된 길이의 요약 (체크섬 또는 해시)**으로 만듬.
2. 노드 A (암호화): 노드 A는 그 요약에, 개인 키를 매개변수로 하는 '서명' 함수를 적용. 이 암호화된 요약이 바로 디지털 서명이 됨.
3. 전송: 서명이 계산되면 메시지와 그에 대한 서명을 둘 다 노드 B에게 전송.
4. 노드 B (검증): 노드 B는 개인 키로 암호화 된 서명에 공개 키를 이용한 역함수를 적용하여 원래의 요약을 얻음.
5. 노드 B (비교): 노드 B는 수신한 메시지를 가지고 자체적으로 요약을 다시 계산하여 (1단계와 동일한 방식으로), 복호화된 요약과 비교함.
   • 만약 요약이 B의 요약과 일치하지 않는다면, 송신 중에 위조된 것 또는 발송자가 노드 A의 개인 키를 갖고 있지 않은 것.

6. 디지털 인증서

신뢰할 수 있는 기관으로부터 보증받은 사용자나 회사에 대한 정보를 담고 있는 것.

인증서의 내부

디지털 인증서는 다음과 같은 주요 정보를 포함하고 있음.

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

디지털 인증서는 대상과 사용된 서명 알고리즘에 대한 정보뿐 아니라, 대상의 공개키도 담고 있음.

즉, 누구나 디지털 인증서를 만들 수 있지만, 모두가 서명 권한을 얻을 수 있는 것은 아님.

 

X.509 v3 인증서

디지털 인증서에 대한 전 세계적인 표준은 없음. 하지만 오늘날 사용되는 대부분의 인증서가 그들의 정보를 X.509라 불리는 표준화된 서식에 저장하고 있음.

 

서버 인증을 위해 인증서 사용하기

사용자가 HTTPS를 통한 웹 트랜잭션을 시작할 때, 최신 브라우저는 자동으로 접속한 서버에서 인증서를 가져옴. 만약 인증서가 없으면 보안 커넥션은 실패함.

브라우저가 인증서를 받으면 **서명 기관(Certification Authority, CA)**을 검사함.

• 신뢰할 만한 서명 기관이라면 브라우저는 공개키를 이미 알고 있고, 브라우저는 서명을 검증 가능.
• 모르는 서명 기관이라면 사용자에게 해당 서명 기관을 신뢰하는지 확인하기 위한 대화 상자를 보여줌.

7. HTTPS의 세부사항

• HTTP의 가장 유명한 보안 버전으로, 상용 브라우저와 서버에 구현되어 있음.
• HTTP 프로토콜에 대칭, 비대칭, 인증서 기반 암호 기법의 강력한 집합을 결합.

HTTPS 개요

• 보안 전송 계층을 통해 전송되는 HTTP.
• HTTP 메시지를 TCP로 보내기 전에 그것들을 암호화하는 보안계층으로 보냄.

HTTPS 스킴 (Scheme)

URL 스킴(Scheme)을 통해 서버에게 HTTP의 보안 프로토콜 버전을 수행한다고 말해줌.

• http 스킴을 가지고 있다면: 80 포트로 연결하고 일반 HTTP 명령 전송.
• https 스킴을 가지고 있다면: 443 포트로 연결하고 서버와 SSL 보안 매개변수를 교환한 뒤, 암호화된 HTTP 명령 전송.

포트 충돌의 문제

SSL과 HTTP 트래픽 모두가 80번 포트로 도착한다면, 대부분 웹 브라우저는 SSL 트래픽을 잘못된 HTTP로 해석하고 커넥션을 닫음. (따라서 HTTPS는 기본적으로 443 포트를 사용함.)

 

보안 전송 셋업

HTTPS를 통한 통신은 다음과 같은 절차로 시작

• 클라이언트는 웹 서버의 443 포트로 연결한 후 TCP 연결을 시작.
• 클라이언트와 서버는 SSL 매개변수와 교환 키를 협상하면서 SSL 계층을 초기화 (이 과정을 핸드셰이크라고 함).
• 핸드셰이크가 완료되면 SSL 초기화가 완료됨.
• 클라이언트는 요청 메시지를 이제 보안 계층에 보낼 수 있음.
• 메시지는 TCP로 보내지기 전에 암호화 됨.

SSL 핸드셰이크

암호화된 HTTP 데이터가 네트워크를 오가기도 전에, SSL은 아래와 같은 핸드셰이크 데이터를 주고받음.

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

 

서버 인증서

SSL은 서버 인증서를 클라이언트로 전달하고, 클라이언트 인증서를 서버로 전달하는 상호 인증을 지원.

• 오늘날 클라이언트 인증서는 흔히 쓰이지 않음.
• 보안 HTTPS 트랜잭션은 항상 서버 인증서를 요구.
• HTTPS 인증서는 사이트 정보가 더해진 X.509 인증서.

 

사이트 인증서 검사

웹 브라우저 대부분은 인증서에 대한 간단한 검사를 하고 결과를 더 철저한 검사를 할 수 있는 방법과 함께 사용자에게 알려줌.

• 날짜 검사: 인증서가 유효한지 확인하기 위해 시작 및 종료일을 검사.
• 서명자 신뢰도 검사: 모든 인증서는 인증 기관(CA)에 의해 서명되어 있음.
• 서명 검사: 서명 기관을 믿으면 브라우저는 서명 기관의 공개키를 서명에 적용하여 체크섬과 비교하며 무결성을 검사.
• 사이트 신원 검사: 인증서의 도메인 이름이 대화 중인 서버의 도메인 이름과 비교하여 맞는지 검사.

가상 호스팅과 인증서

하나의 서버에 여러 호스트 명으로 운영되는 사이트의 보안 트래픽을 다루는 것은 까다로움.

• 보안 트랜잭션을 시작하는 모든 사용자를 리다이렉트시켜서 관리

9. 프락시를 통한 보안 트래픽 터널링

클라이언트는 웹 서버에 접근해주는 웹 프락시 서버를 이용

많은 회사가 기업 네트워크와 공공 인터넷을 잇는 경계에 보안을 위한 프락시를 설치

이 프락시는 방화벽 라우터가 HTTP 트래픽의 교환을 허락한 유일한 장치, 바이러스 검사나 기타 콘텐츠 제어를 수행

 

단, 클라이언트가 서버로 보낼 데이터를 암호화하기 시작했다면, 프락시는 더 이상 HTTP 헤더를 읽을 수 없음

HTTPS 터널링 프로토콜

클라이언트(브라우저)는 HTTPS 통신을 시작하기 위해 프록시 서버에 CONNECT HTTP 메서드를 사용해 요청을 보냅니다.

• 목적: 클라이언트가 프록시 서버에게 목적지 서버의 특정 포트(대부분 443)로 TCP 연결을 설정해 달라고 요청

CONNECT 요청을 받은 프록시 서버는 다음과 같이 동작

• 프록시 서버는 요청된 목적지 서버(secure.example.com)의 지정된 포트(443)로 새로운 TCP 연결을 시도
• 프록시 서버는 클라이언트의 요청 내용을 목적지 서버에 전달하지 않고 오직 연결만을 시도

터널 확립

• 연결 성공 시: 프록시 서버가 목적지 서버와 TCP 연결을 성공적으로 맺으면, 클라이언트에게 200 Connection Established라는 응답을 보냄
• 결과: 이 응답이 클라이언트에게 도착하는 순간, 클라이언트와 목적지 서버 사이에 프록시를 통과하는 직접적인 TCP 터널이 논리적으로 확립

암호화 통신 시작 (SSL/TLS 핸드셰이크)

터널이 확립된 후에는 암호화된 통신이 시작되며, 프록시 서버는 단순히 데이터를 전달하는 역할