[http 완벽 가이드] 14장 보안 HTTP

이 내용은 http 완변 가이드란 책을 읽고 정리한 내용입니다.

 

더 자세한 내용이 궁금하시면 책을 직접 읽어보시는 걸 추천합니다.

 

14장 보안 HTTP

1. HTTP를 안전하게 만들기

• 이전 장에서 다뤘던 인증은 대체로 쓸만하지만, 대량 구매, 은행 업무, 혹은 보안 자료 접근을 위해서는 충분히 강력하지 않다.
• 다음을 제공하는 HTTP가 필요하

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

1.1 HTTPS

• HTTPS는 HTTP를 안전하게 만드는 방식 중에서 가장 인기 있는 것이다.
• HTTPS를 사용할 때 , 모든 HTTP 요청과 응답 데이터는 네트워크로 보내지기 전에 암호화 된다.
• 이 보안 계층은 안전 소켓 계층(SSL)혹은 TLS 이 있다.

2. 디지털 암호학

• HTTPS 에 대해 자세히 이야기 하기 전에, 우리는 SSL과 HTTPS 에서 이용되는 암호 인코딩 기법에 대해 약간의 배경 지식을 제공할 필요가 있다.
• 암호
  • 텍스트를 아무나 읽지 못하도록 인코딩하는 알고리즘
• 키
  • 암호의 동작을 변경하는 숫자로 된 매개변수
• 대칭키 암호 체계
  • 인코딩과 디코딩에 같은 키를 사용하는 알고리즘
• 공개키 암호법
  • 비밀 메시지를 전달하는 수백만 대의 컴퓨터를 쉽게 만들 수 있는 시스템
• 디지털 서명
  • 메시지가 위조 혹은 변조되지 않았음을 입증하는 체크섬
• 디지털 인증서
  • 신뢰할 만한 조직에 의해 서명되고 검증된 신원 확인 정보

2.1 비밀 코드의 기술과 과학

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

2.2 암호

• 암호법은 암호라 불리는 비밀 코드에 기반함.
• 암호란 메시지를 인코딩하는 어떤 특정한 방법과 나중에 그 비밀 메시지를 디코딩하는 방법이다.
• 인코딩되기 전의 원본 메시지는 흔히 텍스트 혹은 평문이라고 한다.

2.3 암호 기계

• 오늘날에 암호 알고리즘은 컴퓨터의 성능이 진보하면서 보다 복잡한 암호로 메시지를 빠르고 정확하게 인코딩하고 디코딩하는 기계를 만들기 시작했다.

2.4 키가 있는 암호

• 코드 알고리즘과 기계가 적에 손에 들어갈 수 있기 때문에 , 대부분의 기계들은 암호의 동작방식을 변경할 수 있는 큰 숫자로 된 다른 값을 설정할 수 있는 다이얼이 달려있다.
  • 누군가 기계를 훔쳐가도, 올바른 다이얼 설정(키 값)이 없이는 디코더가 동작하지 않는다.
• 이러한 암호 매개변수를 키라고 부른다.
• 디코딩 과정을 바르게 동작 시키려면 올바른 암호 기계에 입력할 필요가 있다.
• 암호 키는 하나의 암호 기계를 여러 가상 암호 기계의 집합처럼 만들어준다.
• 이 가상 암호 기계들은 서로 다른 키 값을 갖고 있기 때문에 제각각 다르게 동작한다.

2.5 디지털 암호

• 디지털 키 값은 인코딩과 디코딩 알고리즘에 대한 입력값이다.
• 평문 메시지 P , 인코딩 함수 E , 디지털 인코딩 키e 가 주어지면 부호화 된 암호문 C를 생성할 수 이따.
• C = E(P,e) 이다.

3. 대칭키 암호법

• 많은 디지털 암호 알고리즘은 대칭키 암호라 불린다.
  • 이유는 인코딩할 때 사용하는 키와 디코딩 때 사용하는 키가 같기 때문이다.
  • 그 대칭키를 K라고 부르면
• C = E(P,K)
• P= D(C,K) (D는 디코딩함수이다.) 이된다.

3.1 키 길이와 열거 공격

• 키는 단순한 숫자 형태이다. 그럼 공격자가 모든 경우의 수를 대입해보면 키 길이를 알아낼 수 도 있다.
• 하지만 오늘날의 기술에서는 키 비트 표현이 커져서 현실적으로 불가능하다.

3.2 공유키 발급하기

• 대칭키 암호의 단점 중 하나는 발송자와 수신자가 서로 대화하려면 둘 다 공유키를 가져야 한다는 것이다.
• 이는 사이트 입장에서 N개의 노드가 N-1의 상대와 공유키를 발급한다면 , NXN 개의 공유키를 발급해야한다는 단점이 있다.

4. 공개키 암호법

• 공개키 암호 방식은 두 개의 비대칭 키를 사용한다.
• 하나는 호스트의 메시지를 인코딩하기 위한 것이며, 다른 하나는 그 호스트의 메시지를 디코딩하기 위한 것이다.
  • 인코딩 키는 모두를 위해 공개되어 있다. ( 그래서 공개키 방식이라고 부름)
  • 디코딩 키는 호스트만이 가지고 있다.
• 모든 사람이 X 에게 보내는 메시지를 같은 키로 인코딩하지만 , X를 제외한 누구도 메시지를 디코딩할 수 없다.

4.1 RSA

• 공개키 비대칭 암호의 과제는 , 설혹 악당이 아래 내용을 알고 있다 해도 비밀인 개인 키를 계산할 수 없다는 것을 확신시켜 주는 것이다.
  • 공개키( 물론 공개키이므로 누구나 알 수 있다.)
  • 가로채서 얻은 암호문의 일부(네트워크를 스누핑해서 획득)
  • 메시지와 그것을 암호화한 암호문(인코더에 임의의 텍스트를 넣고 실행해서 획득)
• 위 조건을 만족하는 RSA알고리즘은 위 3개를 다 알고있어도 개인키를 알아내는 건 엄청 어렵다고 한다.

4.2 혼성 암호 체계와 세션 키

• 그러나 공개키 암호 방식의 알고리즘은 계산이 느린 경향이 있다.
• 실제론 대칭과 비대칭 방식을 섞은 것이 쓰인다.
  • 예
  • 노드들 사이의 안전한 의사소통 채널을 수립할 때는 편리하게 공개 키 암호를 사용하고 , 이렇게 만들어진 안전한 채널을 통해 임시의 무작위 대칭 키를 생성하고 교환하여 이후의 나머지 데이터를 암호화 할 때는 대칭 키를 사용하는 방식이 흔히 쓰인다.

5. 디지털 서명

• 암호 체계는 메시지를 암호화하고 해독하는 것뿐 아니라 , 누가 메시지를 썻는지 알려주고 그 메시지가 위조되지 않았음을 증명하기 위해 메시지에 서명을 하도록 하는 데에 이용될 수 있다.
• 이때 쓰이는 기법을 디지털 서명이라 부른다

5.1 서명은 암호 체크섬이다.

• 디지털 서명은 메시지에 붙어있는 특별한 암호 체크섬이다. 이들은 두 가지 이점을 가진다.
  • 서명은 메시지를 작성한 저자가 누군지 알려준다. 저자는 저자의 극비 개인 키를 갖고 있기 때문에, 오직 저자만이 이 체크섬을 계산할 수 있다. 체크섬은 저자의 개인 서명처럼 동작한다.
  • 서명은 메시지 위조를 방지한다. 만약 악의적인 공격자가 송신 중인 메시지를 수정했다면 , 체크섬은 더 이상 그 메시지와 맞지 않게 될 것이다. 그리고 체크섬은 저자의 비밀 개인 키에 관련되어 있기 때문에 , 침입자는 그 위조된 메시지에 대한 올바른 체크섬을 날조해낼 수 없을 것이다.

6. 디지털 인증서

디지털 인증서(certs)는 신뢰할 수 있는 기관으로부터 보증 받은 사용자나 회사에 대한 정보를 담고 있다.

6.1 인증서의 내부

인증서는 다음 내용을 담고 있다

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

!https://velog.velcdn.com/images/bahar-j/post/f7e0694e-b4cb-4a41-9959-dad6ba7b8587/image.png

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

1. 사용자가 HTTPS를 통한 안전한 웹 트랜잭션을 시작할 때, 최신 브라우저는 자동으로 접속한 서버에서 디지털 인증서를 가져온다.> 만약 서버가 인증서를 갖고 있지 않다면, 보안 커넥션은 실패

<서버 인증서가 포함하는 필드>

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

1. 브라우저가 인증서를 받으면, 서명 기관을 검사
   •  

만약 그 기관이 공공이 신뢰할만한 서명 기관이라면 브라우저는 그것의 공개키를 이미 알고 있을 것(보통 브라우저에 여러 서명 기관의 인증서가 미리 설치된 상태)

1. •  
   •  

만약 서명 기관이 모르는 곳이라면, 서명 기관을 신뢰하는지 확인하기 위한 대화상자를 보여줌

1. •  
2. '디지털 서명'에서 이야기했던 바와 같이 브라우저는 서명을 검증

7. HTTPS 의 세부사항

7.1 HTTPS 개요

• HTTPS 는 그냥 보안 전송 계층을 통해 전송되는 HTTP이다.
• 암호화되지 않은 HTTP메시지를 TCP를 통해 전 세계의 인터넷 곳곳으로 보내는 대신에 HTTPS는 HTTP 메시지를 TCP로 보내기 전에 먼저 그것들을 암호화하는 보안 계층으로 보낸다.

• 오늘날, HTTPS 보안 계층은, SSL과 그것의 현재덕 대체품인 TLS 로 구현 되었다.
• SSL 과 TLS 모두들 의미하는 단어로 SSL을 사용하는 관행을 따른다.

7.2 HTTPS 스킴

• HTTPS 프로토콜을 사용한다면 스킴은 https 이고
• 포트번호는 443을 기본값으로 가진다.

7.3 보안 전송 셋업

• HTTP는 트랜잭션을 위해 TCP 커넥션을 맺고 트랜잭션을 수행한다.
• 하지만 HTTPS 는 SSL 보안계층 때문에 조금 더 복잡하다.
• HTTPS 는 TCP 커넥션을 맺고 SSL 핸드 셰이크를 수행한다.
• 클라이언트와 서버는 암호법 매개변수와 교환 키를 협상하면서 SSL 계층을 초기화 한다.
• 그리고 TCP로 요청을 보내기전 암호화된 메시지를 보낸다.

7.4 SSL 핸드셰이크

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

• SSL 핸드셰이크 과정은 더 복잡해질 수 있지만 , 일반적인 과정은 위와 같다.

5.7 서버 인증서

• SSL은 서버 인증서를 클라이언트로 나르고 다시 클라이언트 인증서를 서버로 날라주는 상호 인증을 지원한다.
  • 그러나 오늘날에는 잘 사용하지않는다.
  • 이유는 대부분의 사용자는 개인 클라이언트 인증서를 갖고 있지도 않다.
• 웹 서버는 인증서를 요구할 수 있지만 , 실제로는 좀처럼 일어나지 않는 일이다.
• 한편 , 보안 HTTPS 트랜잭션은 항상 서버 인증서를 요구한다.
• 누군가가 웹 서버에 신용카드 정보를 보내는 것과 같은 보안 트랜잭션을 수행할 때, 그는 대화 중인 조직이 그와 대화하고 있다고 생각한 그 조직이 맞는지 알고 싶을 것이다.

7.6 사이트 인증서 검사

<웹 서버 인증서 검사를 위한 알고리즘의 수행 단계>

1. 날짜 검사

브라우저 인증서가 여전히 유효함을 확인

2. 서명자 신뢰도 검사

만약 신뢰할 만한 CA가 A 사이트에 서명을 하고, A 사이트가 어떤 사이트 인증서에 서명을 한다면, 브라우저는 그 인증서를 올바른 CA 경로에서 파생된 것으로 받아들일 수 있음

3. 서명 검사

서명 기관이 믿을 만하다고 판단하면, 브라우저는 서명기관의 공개키를 서명에 적용하여 그의 체크섬과 비교해봄으로써 인증서의 무결성을 검사

4. 사이트 신원 검사

대부분의 브라우저는 인증서의 도메인 이름이 대화 중인 서버의 도메인 이름과 비교하여 맞는지 검사

•  

몇몇 CA는 와일드카드 표현이 들어있는 인증서를 만들기도 함 (ex. *.google.com)

•  

7.7 가상 호스팅과 인증서

사용자가 인증서의 이름과 정확히 맞지 않는 가상 호스트 명에 도착했다면 경고 팝업이 뜸

• 가상 호스팅인 경우도 그럴 수 있음
• 이런 문제를 피하기 위해 웹사이트는 보안 트랜잭션을 시작한 모든 사용자를 서버 인증서에 있는 호스트 명으로 리다이렉트

8. 진짜 HTTPS 클라이언트

• SSL은 복잡한 바이너리 프로토콜이다.
• 독자가 암호 전문가가 아닌 이상, 가공되지 않은 SSL 트래픽을 직접 보내지 마라.
• SSL 클라이언트와 서버 프로그래밍을 쉽게 만드러주는 상용 혹은 오픈 소스 라이브러리들이 존대한다.

8.1 OpenSSL

OpenSSL 은 SSL 고 TLS의 가장 인기 있는 오픈 소스 구현이다. OpenSSL 프로젝트는 강력한 다목적 암호법 라이브러리인 동시에 SSL 과 TLS 프로토콜을 구현한 강건하고 완전한 기능을 갖춘 사용 수준의 툴킷을 개발하고자 한 자원봉사자들이 협업한 결과물이다.

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

• 클라이언트와 서버 사이에는 프락시 서버를 이용한다.
• 그러나 클라이언트가 서버로 보낼 데이터를 서버의 공개키로 암호화하기 시작했다면, 프락시는 더 이상 HTTP 헤더를 읽을 수 없다.
  • 읽을 수 없다면 프락시는 메시지를 어디에 보낼지 모른다.
• 이를 해결한 방법은 HTTPS SSL 터널링을 이용하는 것이다.
• 8장을 보면 자세히 알 수 있다.