14. Secure HTTP

앞선 3개의 장에서 사용자를 식별하고 인증하는 것을 도와주는 기법들은 우호적인 관계가 형성된 커뮤니티에서는 잘 동작하지만, 적대행위가 일어날 가능성이 있는 커뮤니티에서 트랜잭션을 보호하기에는 부족하다.

디지털 암호화를 이용해 도청이나, 위조로부터 HTTP 트랜잭션을 안전하게 보호하는 더 복잡하고 적극적인 기술을 살펴보자.

1) HTTP를 안전하게 만들기

웹 트랜잭션은 중요한 일에 사용되므로, 웹은 안전한 방식의 HTTP 를 필요로 한다. (= 강력한 보안이 필요하다.)

앞선 기본인증, 다이제스트 인증은 '대량구매', '은행업무', '보안 자료접근' 을 위해서는 충분히 강력하지 않다.

보다 중요한 트랜잭션을 위해 HTTP 와 디지털 암호화 기술을 결합해야한다.

HTTP 보안버전은

1. 효율적이고
2. 이식성이 좋아야하고
3. 관리가 쉬워야하고
4. 현실세게의 변화에 대한 적응력이 좋아햐하고
5. 사회와 정부의 요구사항에도 맞아야한다.

다음을 제공할 수 있는 HTTP 보안 기술이 필요하다.

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

① HTTPS

• HTTPS는, HTTP를 안전하게 만드는 방식 중 가장 인기 있는 방식이다.

• 모든 HTTP 요청과 응답 데이터는 네트워크로 보내지기전 암호화 된다.

• HTTP 에 S (Secure Socket)을 추가한 것이다.

• HTTP 하부에 전송레벨 암호 보안 계층을 제공함으로써 동작한다.

  • SSL (Secure Sockets Layer, 안전 소켓 계층)

    • 어려운 인코딩, 디코딩 작업(암호화)이 대부분 SSL 라이브러리 내부에서 일어난다. 따라서, HTTPS를 사용하기위해 웹클라이언트와 서버가 프로토콜을 처리하는 로직을 크게 변경할 필요 없다.

  • TLS (Transport Layer Security, 전송 계층 보안)

    • 데이터 무결성을 제공한다. 데이터 전송중에 수정되거나 손상되는것을 방지하고 사용자가 자신이 의도하는 웹사이트와 통신하고 있음을 인증하는 인증 기능도 제공.

• 보안 외 장점

  • 검색 엔진 최적화 (SEO): 사용자는 안전하다 생각하는 사이트를 더 자주 방문하기 때문.

  • 가속화된 모바일 페이지(AMP, Accelerated Mobile Page) : HTML의 불필요한 부분 제거한 것

2) 디지털 암호학

(디지털 암호학의 가장 중요한 기본적인 내용: 2) ~ 6))에서 다룬다.
### 그 전에 몇가지 용어정리
- **암호**: 텍스트를 아무나 읽지 못하도록 인코딩하는 알고리즘
- **키**: 암호의 동작을 변경하는 숫자로 된 매개변수
- **대칭키 암호 체계**: 인코딩과 디코딩에 같은 키를 사용하는 알고리즘
- **비대칭키 암호 체계**: 인코딩과 디코딩에 다른 키를 사용하는 알고리즘
- **공개키 암호법**: 비밀 메세지를 전달하는 수백만 대의 컴퓨터를 쉽게 만들 수 있는 시스템
- **디지털 서명**: 메세지가 위조 혹은 변조되지 않았음을 입증하는 체크섬
- **디지털 인증서**: 신뢰할 만한 조직에 의해 서명되고 검증된 신원 확인 정보

① 비밀 코드의 기술과 과학

암호법(Cryptography, 암호학)

• 메세지 인코딩과 디코딩에 대한 과학이자 기술이다.

• 사람들은 수천년간 암호법의 방법론을 비밀 메세지를 보내는데 적용해왔다.

• 메세지를 암호화할 뿐만 아니라, 메세지 변조를 방지하기 위해 사용할 수도 있다.

• 어떤 메세지나, 트랜잭션의 저자임을 증명하는데도 사용할 수 있다.

② 암호(cipher)

• 암호법은 암호라 불리는 비밀코드에 기반한다.

• 암호란, 메시지를 인코딩하는 어떤 특정한 방법과 나중에 그 비밀메시지를 디코딩하는 방법.

• 평문(=텍스트): 인코딩 되기 전 원본 메시지

• 암호문: 암호가 적용되어 코딩된 메시지

③ 암호 기계

• 암호는 상대적으로 간단한 알고리즘으로 시작했었다. 사람이 직접해야했기 때문.

  그래서 똑똑한 사람이 비교적 간단히 암호를 깨뜨리는게 가능했다.

• 기술이 진보하면서, 보다 복잡한 암호로 메시지를 빠르고 정확히 인코딩 & 디코딩하는 기계를 만들었다.

  암호를 깨뜨리기 어렵도록 단순회전대신 글자 대체, 순서변경, 메세지를 자르고 토막냄.

④ 키가 있는 암호

• 코드 알고리즘과 기계가 적의 손에 들어갈 수 있기 때문에, 대부분의 기계들에는 암호 동작 방식을 변경할 수 있는, (큰 숫자로 된) 다른 값을 설정할 수 있는 다이얼이 달려있다.

• 누군가 기계를 훔치더라도 올바른 다이얼 설정값(키 값) 없이 디코더가 작동하지 않을 것이다.

• 이런 암호 매개변수를 키 라고 부른다.

• 디코딩 과정을 바르게 동작시키려면 올바른 키를 암호 기계에 입력할 필요가 있다.

• 암호 키는 하나의 암호 기계를 여러 가상 암호기계의 집합처럼 만들어준다. 각 가상 암호 기계들은 서로 다른 키 값을 가지고 있기 때문에 제각각 다르게 동작한다.

⑤ 디지털 암호

디지털 계산의 도래로 2가지 주요 발전이 있었다.

• 속도 및 기능에 대한 기계 장치의 한계에 벗어남으로써, 복잡한 인코딩과 디코딩 알고리즘이 가능해짐.

• 매우 큰 키를 지원하는것이 가능해져서 단일 암호 알고리즘으로 키값마다 다른 수조개의 가상 암호 알고리즘을 만들수 있게 됨. 키가 길수록 인코딩의 많은 조합이 가능해지고 무작위로 추측한 키에 의한 크래킹이 어려워 진다.

기계장치의 물리적 금속키나, 다이얼 설정과는 달리 디지털 키는 그냥 숫자에 불과하다.

디지털 키 값은 인코딩과 디코딩 알고리즘에 대한 입력값이다.

코딩 알고리즘은 데이터 덩어리를 받아서, 알고리즘과 키의 값에 근거해서 인코딩하거나 디코딩 하는 함수다.

암호문 = 인코더 (평문, 인코딩 키)
평문 = 디코더 (암호문, 디코딩 키)

3) 대칭키 암호법

• 많은 디지털 암호 알고리즘은 대칭키 암호라 불린다.

• 인코딩할 때 사용하는 키가 디코딩할 때 사용하는 키와 같기 때문이다.

• 대칭키 암호에서 발송자, 수신자 모두 통신을 위해 비밀키를 똑같이 공유할 필요가 있다.

  • 발송자는 공유된 비밀 키를, 메세지를 암호화하고 결과를 암호문 수신자에게 발송하기 위해 사용.

  • 수신자도 암호문을 받은뒤 공유된 키로 원래의 평문을 복원.

• 잘 알려진 대칭키 암호화 알고리즘: DES, Triple-DES, RC2, RC4

① 키 길이와 열거 공격 Enumeration Attack

• 비밀키가 누설되면 안된다는 것은 매우 중요하다.

  (대부분 인코딩, 디코딩 알고리즘은 공개되있으므로, 키만이 유일한 비밀이다.)

• 좋은 암호 알고리즘: 공격자가 코드를 크래킹하기 위해 모든 가능한 키값을 시도해보는 수 외에 방법이 없도록.

• 열거 공격: 무차별로 모든 키 값을 대입해보는 공격.

• 가능한 키 값이 많을 수록(비트 수가 클수록) 암호를 깰 하나를 찾기 위해 엄청난 시간을 들여야한다.

• 128bit 키를 사용한 대칭키 암호는 매우 강력하다고 간주한다.

② 공유키 발급하기

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

• 만약 누군가 쇼핑몰에서 은밀하게 대화를 다누려면 개인 비밀 키가 발급되어야 한다.

  • 관리해야하는 쇼핑몰 입장에서는 개인 비밀키를 생성하고 기억해야하니, 관리하는게 복잡하다.

    예: N개의 노드와 각 노드가 상대 N-1 과 은밀히 대화하고싶다면 N^2 개의 비밀키가 필요함.

4) 공개키 암호법

01

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

  • 하나는 호스트의 메세지를 인코딩하기 위해서 사용. (모두를 위해 공개)

  • 다른 하나는 그 호스트의 메세지를 디코딩하기 위해서 사용. (호스트만 알고있음)

• 모든 사람이 X에게 보내는 메세지를 같은 키로 인코딩이 가능하지만, X를 제외한 누구도 디코딩을 할 수 없다.

  오직 X만 디코딩 개인키를 가지고 있기 때문이다.

• 키의 분리는 메세지의 인코딩은 누구나 가능하게하는 동시에, 디코딩 능력은 소유자에게만 부여한다.

• 각 노드가 서버로 안전하게 메세지를 발송하는 것을 좀 더 쉽게 하는데, 왜냐하면 서버의 공개키만 있으면 되기 때문.

① RSA

• 공개키 비대칭 암호의 과제는 악당이 아래 내용을 알고 있다고 하더라도 비밀인 개인 키를 계산할 수 없다는 것을 확신시켜 주는 것이다.

  1. 공개키

  2. 가로채서 얻은 암호문의 일부 - 네트워크를 스누핑해서 획득

  3. 메세지와 그것을 암호화한 암호문 - 인코더에 임의의 텍스트를 넣고 실행해서 획득

• 이 모든 요구를 만족하는 공개키 암호 체계중 유명한 하나는 RSA 알고리즘이다.

② 혼성 암호 체계와 세션키

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

• 실제로는 대칭과 비대칭 방식을 섞은 것이 쓰인다.

5) 디지털 서명

• 암호 체계는 메시지를 암호화하고 해독하는 것 뿐 아니라

  누가 메세지를 썼는지 알려주고, 위조되지 않았음을 증명하기 위해

  메세지에 서명 하도록 하는데 이용될 수 있다.

• 디지털 서명(digital sigining) 기법은 인터넷 보안 인증에 중요하다.

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

디지털 서명은 메세지에 붙어있는 특별한 암호 체크섬이다. 이들은 2가지 이점을 가진다.

• 서명은 메시지를 작성한 저자가 누구인지 알려준다.

  저자는 저자 극비 개인키를 갖고 있기 때문에, 오직 저자만이 이 체크섬을 계산할 수 있다.

• 서명은 메시지 위조를 방지한다.

  악의적인 공격자가 송신 중인 메시지를 수신하면 체크섬은 더이상 그 메시지와 맞지 않다.

  체크섬은 저자의 비밀 개인키에 관련이 있기 때문에 침입자는 위조된 메시지에 대한 올바른 체크섬을 날조할수 없다.

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

개인키는 오직 소유자만 알고있기 때문에 저자의 개인키는 일종의 '지문' 처럼 사용된다.

6) 디지털 인증서

인터넷의 신분증 (디지털 인증서는 흔히 certs라고 부른다.)

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

신뢰할만한 신원 증명언

• 서명이 되어있고

• 틀별한 종이위에

• 정부가 새긴 도장이 찍혀있다.

위조하기 어렵고, 본질적으로 더 높은 신뢰를 받게 된다.

① 인증서 내부

공식적으로 '인증 기관' 에 의해 디지털 서명된 정보의 집합이 담겨있다.

• 대상의 이름 (사람, 서버, 조직 등)

• 유효기간

• 인증서 발급자 (누가 이 인증서를 보증하는가?)

• 인증서 발급자의 디지털 서명

디지털 인증서는 대상과 사용된 서명 알고리즘에 대한 서술적인 정보, 대상의 공개키도 담고 있다. 누구나 디지털 인증서를 만들 수 있지만, 모두가 인증서의 정보를 보증하고 인증서의 개인 키로 서명할 수 있는 널리 인정받는 서명 권한을 얻을 수 있는 것은 아니다.

② X.509 v3 인증서

디지털 인증서에 대한 전세계 단일 표준은 없지만, 오늘날 사용되는 대부분의 인증서가 X.509라 불리는 표준 서식에 저장하고 있다. X.509 v3 인증서는 인증 정보를 파싱 가능한 필드에 넣어 구조화 된 방법을 제공한다.

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

사용자가 HTTPS를 통한 안전한 웹 트랜잭션을 시작할 때, 최신 브라우저는 자동으로 접속한 서버에서 디지털 인증서를 가져온다.

만약 서버가 인증서를 가지고 있지 않다면 보안 커넥션은 실패한다.

[절차]

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

  • 신뢰할만한 서명기관일 경우, 브라우저는 그것의 공개키를 이미 알고 있을 것이며, 서명을 검증할수 있다.

  • 서명기관이 모르는 곳이라면 브라우저는 신뢰해야할지 확신이 불가하므로, 사용자가 서명기관을 신뢰하는지 확인하기 위한 대화상자를 보여준다.

7) HTTPS 의 세부사항

• HTTP의 가장 유명한 보안 버전.

• 널리 구현되어 있고 주류 상용 브라우저, 서버에 구현되어 있다.

• HTTP 프로토콜에 대칭, 비대칭 인증서 기반 암호 기법의 강력한 집합을 결합한 것이다.

• 무정부 상태의 분권화된 글로벌 인터넷 환경에서도 매우 안전한 동시에 유연하고 관리하기 쉽게 만든다.

• 인터넷 어플리케이션 성장, 웹기반 전자상거래 고속 성장을 이끄는 주력이다.

• 분산화된 웹 애플리케이션의 광역 보안 관리에 중요하다.

① HTTPS 개요

• 보안 전송 계층을 통해 전송되는 HTTP 이다. TCP로 보내기 전에 먼저 암호화하는 보안계층으로 보낸다.

• HTTPS 의 보안 계층은 SSL 과 그것의 현대적 대체품인 TLS로 구현되었다.

• SSL과 TLS를 모두 의미하는 단어로 'SSL' 을 사용하는 관행을 따른다.

② HTTPS 스킴

• 오늘날 보안 HTTP는 선택적이다.

• 웹서버에게 HTTP의 보안 프로토콜 버전을 수행한다고 말해줄 방법이 필요한데, URL의 스킴을 이용한다.

• 클라이언트(웹 브라우저 등)는 웹 리소스에 대한 트랜잭션 수행을 요청받으면 URL의 스킴을 검사한다.

  • 만약 http 스킴을 가지고 있다면 서버에 80번 포트(기본값)로 연결하고, 평범한 http 명령을 전송한다.

  • 만약 https 스킴을 가지고 있다면 서버에 443번 포트(기본값)로 연결하고

    서버와 바이너리포맷으로 된 몇몇 SSL 보안 매개변수를 교환하면서 '핸드셰이크'를 하고

    암호화된 HTTP 명령이 뒤를 잇는다.

③ 보안 전송 셋업

[HTTPS 트랜잭션 절차]

1. 웹서버의 443번 포트로 연결한다. TCP 연결이 되고나면
2. 클라이언트와 서버는 암호법 매개변수와 교환 키를 협상하면서 SSL 계층을 초기화한다.(SSL핸드셰이크)
3. 핸드셰이크가 완료되면 SSL 초기화는 완료되며 클라이언트는 요청 메세지를 보안 계층에 보낼 수 있다.
4. 이 메세지는 TCP로 보내지기 전에 암호화된다. 암호화된 요청을 보낸다.
5. SSL을 통해 보내진 HTTP 요청 / TCP를 통해 보내진 암호화된 요청
6. SSL 닫힘을 통지한다.
7. TCP 커넥션이 닫힌다.

④ SSL 핸드 셰이크

암호화된 HTTP 메세지를 보낼 수 있게 되기 전에 클라이언트와 서버는 SSL 핸드셰이크를 할 필요가 있다.

[핸드셰이크에서 일어나는 일]

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

암호화된 HTTP 데이터가 네트워크를 오가기도 전에 SSL은 통신을 시작하기 위해 상당한 양의 핸드 셰이크 데이터를 주고받는다. SSL 이 어떻게 사용되는가에 따라서 핸드셰이크는 보다 복잡해질수도 있다.

⑤ 서버 인증서

• SSL 인증서: 클라이언트 - 서버간 통신을 제 3자가 보증해주는 전자화된 문서

• SSL은 서버 인증서를 클라이언트로 나르고, 다시 클라이언트 인증서를 서버로 날라주는 상호 인증을 지원.

• 오늘날 클라이언트 인증서는 웹브라우징에서 잘 사용되지는 않는다.

• 한편, 보안 HTTPS 트랜잭션은 항상 서버 인증서를 요구한다.

• 서버 인증서는 조직의 이름, 주소, 서버 DNS 도메인이름, 그외 정보를 보여주는

  X.509 v3에서 파생된 인증서이다.

• 사용자와 사용자의 클라이언트 sw는 모든것이 믿을만한지 확인하기 위해 인증서를 검증할 수 있다.

⑥ 사이트 인증서 검사

SSL 자체는 사용자에게 웹서버 인증서를 검증할 것을 요구하지 않지만, 최신 웹 브라우저들 대부분은 인증서에 대해 간단한 기본검사를 하고 그 결과를 더 철저한 검사를 할 수 있는 방법과 함께 사용자에게 알려준다.

⑦ 가상 호스팅과 인증서

가상 호스트(하나의 서버에 여러 호스트명)로 운영되는 사이트의 보안 트래픽을 다루는 것은 까다로운 경우도 많다

8) 진짜 HTTP 클라이언트

• SSL은 복잡한 바이너리 프로토콜이다.

• 몇가지 SSL 클라이언트와 서버 프로그래밍을 쉽게 만들어주는 상용, 혹은 오픈 소스 라이브러리들이 존재한다.

① OpenSSL

• SSL과 TLS의 가장 인기 있는 오픈소스 구현이다.

• 강력한 다목적 암호법 라이브러리

• SSL과 TLS 프로토콜을 구현한 강건하고 완전한 기능을 갖춘 상용수준의 툴킷을 개발하고자 한 자원봉사자들의 협업 결과물이다.

• SSLeay 라이브러리를 계승하였고 인터페이스가 매우 비슷하다.

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

클라이언트는 종종 그들을 대신하여 웹 서버에 접근해주는 웹 프락시 서버를 이용한다.

프락시는 암호화된 요청을 다룰 수 없다.

HTTPS가 프락시와도 잘 동작할 수 있도록, 클라이언트가 프락시에게 어디에 접속하려하는지 말해주는 방법을 약간 수정해야한다.

인기있는 기법중 1가지는 HTTPS SSL 터널링 프로토콜이다. 이 프로토콜을 사용해서 클라이언트는 먼저 프락시에게 자신이 연결하고자하는 안전한 호스트와 포트를 말해준다. 이 내용을 읽을 수 있도록 암호화가 시작되기 전의 평문으로 말해준다.

HTTP는 CONNECT라는 새로운 확장 메서드를 사용하여 평문 종단 정보를 보내는 데 사용된다.

• CONNECT 메서드로 프락시에게 희망하는 호스트와 포트번호로 연결해달라고 말한다.

• 클라이언트와 서버 사이에 데이터가 직접 오가는 터널을 만단다.

커넥션을 수립하기 위한 핸드셰이크가 성공하면 SSL 데이터 전송이 시작된다.

[참조자료]

• HTTP 와 HTTPS 차이(1.① 정리): 링크