[HTTP] 20. 보안 HTTP

14.1 HTTP를 안전하게 만들기

HTTP 보안 버전은 효율적이고 이식성이 좋아야 하고 관리가 쉬워야 하며 현실 세계의 변화에 대한 적응력이 좋아야 한다. ⇒ 이를 위해서 아래의 것이 필요하다.

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

⇒ 정리하자면, 서버와 클라이언트가 서로가 누군지 분명히 아는 상태에서, 서로만이 알아볼 수 있게 암호화를 해야 하고, 여기서 데이터의 손실이 있어서는 안 된다. 추가적으로 속도도 빨라야 하며, 이 프로토콜이 지원이 잘 되어야 한다. 또 레거시인 프로그램에서도 발전시키는 데 애로사항이 없어야 한다. 정도로 생각하면 되겠다. HTTP에서 보안이 추가된다고 해서 다른 단점이 발생하면 안 된다는 느낌이다.

14.1.1 HTTPS

HTTPS는 HTTP 요청과 응답 데이터를 네트워크로 보내기 전에 암호화하는 프로토콜을 말한다. 애플리케이션 계층에 있는 HTTP와 전송 계층이던 TCP 사이에 SSL 혹은 TLS이라는 보안 계층이 끼어 있는 구조.

따라서 어려운 인코딩 및 디코딩 작업은 SSL 라이브러리 내에서 일어나기 때문에 HTTPS를 사용한다고 해서 서버와 클라이언트의 로직을 크게 변경할 필요가 없다.

14.2 디지털 암호학

용어 설명

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

14.2.1 비밀 코드의 기술과 과학

14.2.2 암호(cipher)

암호 + 평문 = 암호문, 예시로 카이사르 암호를 들었다.

14.2.3 암호 기계

암호를 만드는 기계.

14.2.4 키가 있는 암호

암호를 할 때 특정한 키 값을 받아서 암호를 만들 수 있다. 예를 들면 카이사르 암호를 만들 때, n이라는 숫자를 받아 그 만큼의 rotation을 가진 암호문을 만드는 것이다.

14.2.5 디지털 암호

디지털 계산의 도래로, 복잡한 인코딩, 디코딩 알고리즘이 가능해지고, 매우 큰 키 값을 지원할 수 있게 되었다. 따라서 단일한 암호 알고리즘 가지고도 수조 개의 알고리즘을 파생할 수 있게 되었다.

14.3 대칭키 암호법

인코딩의 키가 디코딩의 키와 같을 경우를 대칭 키 암호법이라고 한다.

14.3.1 키 길이와 열거 공격 (Enumeration Attack)

비밀 키는 누설되면 안 된다. 대부분의 경우 인코딩 및 디코딩 알고리즘은 공개적으로 알려져 있다. ( 오픈 소스이다. ) 따라서 키만이 유일한 비밀이다.

좋은 알고리즘은 공격자가 코드를 크래킹하기 위해서 가능한 모든 키를 시도해보는 것 말고는 방법이 없게 한다. 이렇게 무차별적으로 모든 키를 대입하는 것을 열거 공격이라고 한다.

좋은 알고리즘은 이 열거 공격의 '모든 키'가 매우 많아서 공격하는 사람으로 하여금 엄청난 시간을 들이게 한다.

14.3.2 공유키 발급하기

대화를 하는 두 대상은 하나의 키를 공유해야 한다. 이 때, A,B,C가 J와 대화를 원하면 3개의 키가 있으면 되지만, 각자와 대화를 하고자 하면 N^2개의 키가 발급되어야 한다. 이는 관리가 매우 힘들다.

14.4 공개키 암호화

한 쌍의 호스트마다 키를 발급하는 대신에 한 쌍의 키만을 발급하는 방식으로, 이 때, 인코딩은 모두에게 공유가 되고, 디코딩 키는 오직 호스트가 가지는 방식을 의미한다.

따라서 누구나 암호를 만들 수 있지만 해독은 반드시 호스트만이 가능하다. 이 때, 호스트를 경유하는 방식으로 대화를 하면 키는 N+1개만 있어도 대화가 가능하다. ( 한 개는 디코딩을 위한 키이다. )

이 방식의 표준화는 아직도 진행 중이다.

14.4.1 RSA

암호화는 악성 유저가 공개 키 ( 당연히 공개되어 있으니 악성 유저도 키를 가지고 있다. ), 그리고 그 키를 이용해 만든 암호를 통해 가로챈 암호문의 일부를 해독하는 것을 불가능하게 하는 게 과제이다.

이를 만족하는 것 암호화 방법 중 하나가 RSA 알고리즘이다. ( 이는 가장 큰 소수를 찾는 알고리즘을 구하는 것만큼이나 어려워서, 풀 수만 있으면 튜링상을 받을 수 있다고 한다... )

14.4.2 혼성 암호체계와 세션 키

다만 호스트를 거쳐서 대화를 하는 방식은 느리다. 따라서 공개 키를 사용하여 임시의 무작위 대칭 키를 생성하여 사용하도록 하는 방식을 말한다.

⇒ 세션에 이런 비밀이 있었다니...

14.5 디지털 서명

암호 체계는 메시지를 암호화하고 해독할 뿐만 아니라, 누가 메시지를 썼고, 또한 위조되지 않았음을 증명해주기 위해 서명을 하는 용도로도 이용될 수 있다.

14.5.1 서명은 암호 체크섬이다

• 서명은 작성자가 누군지 알려준다. 작성자는 극비 개인 키를 가지고 있기 때문에, 오직 저자만이 이 체크섬을 계산할 수 있다. 체크 섬이 곧 개인 서명으로 동작하는 셈이다.
  • 이 개인 키가 위조되지 않았다고 가정한다. 개인 키는 일정 시간이 지나면 만료된다.
    • 훔쳤거나 훼손된 키를 사용한 경우를 잡아내기 위해 폐기 목록에 만료된 키들을 저장해두기도 한다.
• 서명은 메시지 위조를 방지한다. ( 누군가 메시지를 중간에 수정했다면 그 메시지는 체크섬에 맞지 않게 된다. )

디지털 서명은 보통 비대칭 공개키에 의해 생성된다.

서명이 만들어지는 것은 아래처럼 이루어진다.

1. 메세지를 일정한 길이로 요약한다.
2. 그 요약에 서명 함수를 사용하여, 서명을 만든다. 이 때, 서명 함수는 개인 키와 관련이 있다.
3. 만들어진 서명을 메시지의 끝에 붙이고, 메시지와 서명을 각각 상대에게 전달한다.
4. 만약 공개키의 역함수로 풀어낸 서명의 메시지가, 평문 메시지와 다르다면 위조된 것이다.

⇒ 이게 뭔 말인지, 4번을 도저히 모르겠다.

의문점

1. 14.5.1 서명은 암호 체크섬이다의 4번 문항을 이해할 수가 없다. 책의 내용을 잘 옮긴 게 맞는지도 모르겠다.

14.6 디지털 인증서

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

14.6.1 인증서의 내부

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

14.6.2 X.509 v3 인증서

디지털 인증서에 대한 표준은 없지만, 대부분은 이 X.509라는 서식을 사용하고 있다.

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

HTTPS를 통한 웹 트래잭션을 시작할 때, 브라우저는 자동으로 디지털 인증서를 가져 온다. 서버가 인증서가 없다면 보안 커넥션은 실패한다. 인증서는 아래의 필드를 가진다.

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

브라우저는 인증서를 받아 서명 기관을 검사한다. 만약 서명 기간이 모르는 곳이라면 대개 사용자에게 파단을 맡기는 대화 상자를 보여준다.

14.7 HTTPS의 세부사항

HTTPS는 HTTP의 보안 버전이다. 이는 웹 기반 전자상거래의 고속 성장을 이끄는 주역이다. 또한 분산된 웹 애플리케이션의 광역 보안 관리에 있어 대단히 중요하다.

14.7.1 HTTPS 개요

암호화되지 않은 HTTP 메시지를 TCP를 통해 전 세계의 인터넷 곳곳으로 보내는 대신, HTTPS는 HTTP를 TCP로 보내기 전에 보안 계층으로 보낸다. ( 보안 계층은 SSL 혹은 TLS 이다. )

오늘 날 보안 계층은, SSL과 그것의 현대적 대체품인 TLS로 구현되었다. 편의 상 SSL로 통칭한다.

14.7.2 HTTPS 스킴

• http를 스킴으로 가지고 있다면 통상적인 방법과 같이 80번 포트를 사용해 웹 트랜잭션을 주고 받는다.
• 만약 https를 스킴으로 갖고 있다면, 클라이언트는 443번 포트로 연결하여 서버와 바이너리 포맷으로 된 SSL 보안 매개 변수를 교환하며 핸드셰이크를 주고 받고 이후 암호화된 HTTP 명령을 건넨다.
• SSL 트래픽은 바이너리 프로토콜이기 때문에 HTTP와는 완전히 다르다. 따라서 HTTPS를 HTTP로 보낼 시에는 잘못된 HTTP로 해석하고 커넥션을 닫게 된다.

14.7.3 보안 전송 셋업

HTTP

1. 서버의 80번 포트로 TCP 커넥션 수립
2. TCP를 통해 보내진 HTTP 요청
3. TCP를 통해 보내진 HTTP 응답
4. TCP 커넥션 종료

HTTPS

1. 서버의 443 포트로 TCP 커넥션 수립
2. SSL 보안 매개변수 핸드셰이크
3. SSL을 통해 보내진 HTTP 요청 / TCP 를 통해 보내진 암호화된 요청
4. SSL을 통해 보내진 HTTP 응답 / TCP 를 통해 보내진 암호화되 응답
5. SSL 닫힘
6. TCP 커넥션 종료

14.7.4 SSL 핸드셰이크

암호화된 HTTP 메시지를 보내기 전에 클라이언트와 서버는 SSL 핸드셰이크를 주고 받아야 한다. 핸드셰이크는 아래의 일을 실행한다.

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

기본적으로, 클라이언트가 암호 후보와 인증서를 보내면 서버는 암호를 하나 선택하고 인증서를 돌려주는 식이다. 이후 클라이언트와 서버는 공통의 키를 만들어 사용한다.

14.7.5 서버 인증서

클라이언트에게 인증서가 필요한 일은 별로 없지만, 서버에게는 인증서가 반드시 필요하다. HTTPS 트랜잭션은 서버에게 반드시 서버 인증서를 요구하게끔 되어 있다.

14.7.6 사이트 인증서 검사

• 날짜 검사
• 서명자 신뢰도 검사
• 서명 검사
• 사이트 신원 검사

14.7.7 가상 호스팅과 인증서

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

14.8 진짜 HTTPS 클라이언트

14.8.1 OpenSSL

가장 인기 있는 SSL, TLS 오픈 소스 구현이다. 강력한 다목적 암호법 라이브러리인 동시에 SSL과 TLS를 통한 강건하고 완전한 기능을 가진 상용 수준의 툴킷이다. ( 또는 그러한 목표를 지향한다. )