디지털 암호화를 이용해 도청이나 위조로부터 HTTP 트랜잭션을 안전하게 보호하는 기술을 알아보자.
HTTP를 안전하게 만들기
- 대량 구매, 은행 업무, 보안 자료 접근을 위해서 보다 강력하고 중요한 트랜잭션을 위해서는, HTTP와 디지털 암호화 기술을 결합해야 함.
- HTTP의 보안 버전을 위해 필요한 조건은 다음과 같음.
- 서버 인증
- 클라이언트는 자신이 위조된 서버가 아닌 진짜와 이야기하고 있음을 알아야 함.
- 클라이언트 인증
- 서버는 자신이 가짜가 아닌 진짜 사용자와 이야기하고 있음을 알 수 있어야 함.
- 무결성
- 클라이언트와 서버는 그들의 데이터가 위조되는 것으로부터 안전해야 함.
- 암호화
- 클라이언트와 서버는 도청에 대한 걱정 없이 서로 대화할 수 있어야 함.
- 효율
- 저렴한 클라이언트나 서버도 이용할 수 있도록 알고리즘은 충분히 빨라야 함.
- 편재성
- 프로토콜은 거의 모든 클라이언트와 서버에서 지원되어야 함.
- 관리상 확장성
- 현재 알려진 회선의 보안 방법을 지원해야 함.
- 사회적 생존성
- 사회의 문화적, 정치적 요구를 만족해야 함.
- HTTPS
- HTTP를 안전하게 만드는 방식 중에서도 가장 인기 있는 방법임.
- 넷스케이프 커뮤니케이션 주식회사에서 개척하였으며 모든 주류 브라우저와 서버에서 지원함.
- URL의 시작이 https://임.
- HTTPS를 사용할 때, 모든 HTTP 요청과 응답 데이터는 네트워크로 보내지기 전에 암호화 됨.
- HTTPS는 HTTP의 하부에 전송 레벨 암호 보안 계층을 제공함으로써 동작하는데, 이 보안 계층은 안전 소켓 계층(Secure Sockets Layer, SSL)혹은 그를 계승한 전송 계층 보안(Transport Layer Security, TLS)를 이용하여 구현됨.
- 어려운 인코딩 및 디코딩 작업은 대부분 SSL 라이브러리 안에서 일어나기 때문에, 보안 HTTP를 사용하기 위해 웹 클라이언트와 서버가 프로토콜을 처리하는 로직을 크게 변경할 필요는 없음.
- 대부분의 경우, TCP 입력/출력 호출을 SSL 호출로 대체하고, 보안 정보를 설정하고 관리하기 위한 몇 가지 호출을 추가하면 됨.
디지털 암호학
SSL과 HTTPS에서 이용되는 암호 인코딩 기법에 대해 약간의 배경 지식을 알아보자.
- 암호법은 메시지 인코딩과 디코딩에 대한 기술임.
- 암호법은 단순히 메시지를 암호화하는 것뿐 아니라, 메시지의 변조를 방지하기 위해 사용할 수 있음.
- 누군가가 정말로 어떤 메시지나 트랜잭션의 저자임을 증명하는 데도 사용될 수 있음.
- 암호(Cipher)
- 암호란 메시지를 인코딩하는 어떤 특정한 방법과 나중에 그 비밀 메시지를 디코딩하는 방법임.
- 인코딩되기 전의 원본 메시지는 흔히 텍스트 혹은 평문이라 부르며, 암호가 적용되어 코딩된 메시지를 보통 암호문이라고 부름.
- 암호 기계
- 옛날엔 수기로 암호를 해독했다면 현재는 기술의 진보로 보다 복잡한 암호로 메시지를 빠르고 정확하게 인코딩하고 디코딩하는 기계를 만들기 시작함.
- 암호 기계는 암호를 어렵게 하기 위해, 단순히 회전을 하는 대신 글자들을 대체하고, 그 순서를 바꾸었으며, 메시지를 자르고 토막냄.
- 키가 있는 암호
- 적의 손에 암호 알고리즘과 기계가 들어갈 수 있기 때문에, 대부분의 기계들에는 암호의 동작방식을 변경할 수 있는 큰 숫자로 된 다른 값을 설정할 수있는 다이얼이 달려있음. 누군가 기계를 훔치더라도, 올바른 다이얼 설정(키 값)이 없이는 디코더가 동작하지 않을 것임.
- 이러한 암호 매개변수를 키라고 부름. 디코딩 과정을 바르게 동작시키려면 올바른 키를 암호 기계에 입력할 필요가 있음.
- 암호 키는 하나의 암호 기계를 여러 가상 암호 기계의 집합처럼 만들어주며, 이 가상 암호 기계들은 서로 다른 키 값을 갖고 있기에 제각각 다르게 동작함.
- 디지털 암호
- 디지털 계산의 도래로, 두 가지 주요한 발전이 있었음.
- 속도 및 기능에 대한 기계 장치의 한계를 벗어남으로써, 복잡한 인코딩과 디코딩 알고리즘이 가능해짐.
- 매우 큰 키를 지원하는 것이 가능해져서, 단일 암호 알고리즘으로 키의 값마다 다른 수조 개의 가상 암호 알고리즘을 만들어낼 수 있게 됨. 이는 무작위 크래킹을 어렵게 함.
- 기계 장치의 물리적인 금속 키나 다이얼 설정과는 달리, 디지털 키는 그냥 숫자에 불과함.
대칭키 암호법
어떻게 키와 암호가 함께 동작하는지 얘기해보자.
- 대칭키는 인코딩할 때 사용하는 키가 디코딩할 때와 같음.
- 대칭키 암호에서, 발송자와 수신자 모두 통신을 위해 비밀 키를 똑같이 공유해야 함.
- 발송자는 공유된 비밀 키를 메시지를 암호화하고 수신자에게 발송함.
- 수신자는 역시 암호문을 받은 뒤 같은 공유된 키를 사용하여 원래의 평문을 복원하기 위해 해독 함수를 적용함.
- 잘 알려진 대칭키 암호 알고리즘으로는 DES, Triple-DES, RC2, RC4 등이 있음.
키 길이와 열거 공격(Enumeration Attack)
- 대부분의 경우, 인코딩 및 디코딩 알고리즘은 공개적으로 알려져 있으므로, 키만이 유일한 비밀임.
- 좋은 암호 알고리즘은 공격자가 코드를 크래킹하려면 이 우주에 존재하는 모든 가능한 키 값을 시도해보는 것 외에 다른 방법이 없게 만드는 것임.
- 무차별적인 키 값 대입 공격을 열거 공격이라 함.
- 대칭키 암호에서는, 보통 모든 키 값이 유효함. 8bit key라면 256가지 값이 가능하며, 40bit key라면 약 1조가지의 값이 가능하고,128bit key라면 약 340,000,000,000,000,000,000,000............ 가지의 값이 가능함.
공유키 발급하기
- 대칭키 암호의 단점 중 하나는 발송자와 수신자가 서로 대화하려면 둘 다 공유키를 가져야 한다는 것임.
- N개의 노드가 있다면 N^2개의 비밀키가 필요함. 이는 여러 사용자가 생겨날때 키를 관리하는 관리자 측면에서 효율적이지 않음.
공개키 암호법
- 한 쌍의 호스트가 하나의 인코딩/디코딩 키를 사용하는 대신, 공개키 암호 방식은 두 개의 비대칭 키를 사용함.
- 하나는 호스트의 메시지를 인코딩하기 위한 것이며, 다른 하나는 그 호스트의 메시지를 디코딩하기 위한 것임.
- 인코딩 키는 모두 공개되어 있지만 호스트만이 개인 디코딩 키를 가지고 있음.
- 키의 분리를 통해 메시지의 인코딩은 누구나 할 수 있도록 해주는 동시에, 메시지를 디코딩하는 능력은 소유자에게만 부여함.
- 이는 서버의 공개 키만 있으면 되기 때문에 노드가 서버로 안전하고 쉽게 메시지를 발송하게 해줌.
- RSA
- MIT에서 발명되고 이어서 RSA 데이터 시큐리티에 상용화된 알고리즘.
- 공개키, 평문의 일부, 공개키로 평문을 인코딩하여 얻은 평문에 대한 암호문, 그리고 RSA 구현의 소스 코드까지 주어졌다 하더라도 암호를 크래킹하여 해당하는 개인키를 찾는 것은 컴퓨터 과학의 모든 분야에서 가장 어려운 문제 중 하나라고 알려진 큰 소수의 계산하는 문제만큼 어려움.
- 혼성 암호 체계와 세션 키
- 비대칭 공개키 암호 방식은 누구나 공개키만 알면 그 키에 대응되는 공개 서버에 안전하게 메시지를 보낼 수 있게 해주므로 훌륭함.
- 하지만 공개키 암호화 알고리즘은 계산이 느린 경향이 있어 실제로는 대칭키와 비대칭키 방식을 섞은 것이 쓰임.
- 예를 들어, 노드들 사이의 통신 채널을 수립할 때는 공개 키 암호를 사용하고, 만들어진 안전한 채널을 통해 임시의 무작위 대칭 키를 생성, 교환하여 나머지 데이터는 대칭 키를 사용함.
디지털 서명
- 암호 체계는 메시지를 암호화하고 해독하는 것뿐 아니라, 누가 메시지를 썼는지 알려주고 그 메시지가 위조되지 않았음을 증명하는 데 사용됨.
- 서명한 저자는 저자의 극비 개인키를 갖고 있기 때문에, 오직 저자만이 이 체크섬을 계산할 수 있음.
- 체크섬이란 오류 검출 방식의 하나. 메시지에 포함된 비트 수에 기반한 수칫값을 전송 메시지에 추가하여 전송함으로써 오류를 검출함.
- 디지털 서명은 보통 비대칭 공개키에 의해 생성됨. 개인 키는 오직 소유자만이 알고 있기 때문에, 저자의 개인 키는 일종의 지문처럼 활용됨.
노드 A가 노드 B에게 메시지를 보내고, 서명하는 절차 a. 노드 A는 가변 길이 메시지를 고정된 길이의 요약(digiest)으로 만든다. 이에 사용자의 개인키를 매개변수로 하는 서명 함수를 적용한다.여기서 디코더 함수 D가 사용된다. b. 노드 A는 계산된 서명과 메시지 모두를 노드 B에게 전송한다. c. 메시지를 받은 노드 B는 서명을 검사할 수 있다. 여기에 공개키를 이용한 역함수를 적용한다. 만약 풀어낸 요약이 노드 B가 가진 버전과 요약이일치하지 않는다면, 위조되었거나 노드 A가 개인키를 갖고 있지 않은 것이다.
디지털 인증서
- 디지털 인증서(cert라 불림)는 신뢰할 수 있는 기관으로부터 보증 받은 사용자나 회사에 대한 정보를 담고 있음.
- 인증서의 내부
- 디지털 인증서에는 공식적으로 인증기관에 의해 디지털 서명된 정보의 집합이 담겨 있음.
- 대상의 이름
- 유효기간
- 인증서 발급자
- 인증서 발급자의 디지털 서명
- 추가적으로 디지털 인증서는 대상과 사용된 서명 알고리즘에 대한 서술적인 정보뿐 아니라 보통 대상의 공개키도 담고 있음.
- 누구나 디지털 인증서를 만들 수 있지만, 그 모두가 인증서의 정보를 보증하고 인증서를 개인키로 서명할 수 있는, 널리 인정받는 서명 권한을 얻는 건 아님.
- X.509 v3 인증서
- 디지털 인증서에 대한 전 세계적인 단일 표준은 없음. 그렇지만 오늘날 대부분의 인증서가 그들의 정보를 X.509라 불리는 표준화된 서식에 저장하고 있음.
- X.509 v3 인증서는 인증 정보를 파싱 가능한 필드에 넣어 구조화하는 표준화된 방법을 제공함.
Certificate: Data: Version: 3 (0x2) Serial Number: 04:00:00:00:00:01:15:4b:5a:c3:94 Signature Algorithm: sha1WithRSAEncryption Issuer: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA Validity Not Before: Sep 1 12:00:00 1998 GMT Not After : Jan 28 12:00:00 2028 GMT Subject: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:da:0e:e6:99:8d:ce:a3:e3:4f:8a:7e:fb:f1:8b: ... Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE X509v3 Subject Key Identifier: 60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B Signature Algorithm: sha1WithRSAEncryption d6:73:e7:7c:4f:76:d0:8d:bf:ec:ba:a2:be:34:c5:28:32:b5: ...
- 서버 인증을 위해 인증서 사용하기
- 사용자가 HTTPS를 통한 안전한 웹 트랜잭션을 시작할 때, 최신 브라우저는 자동으로 접속한 서버에서 디지털 인증서를 가져옴.
- 만약 서버가 인증서를 갖고 있지 않다면 보안 커넥션은 실패함.
- 서버 인증서는 다음을 포함한 많은 필드를 갖고 있음.
- 웹 사이트의 이름과 호스트명
- 웹 사이트이 공개키
- 서명 기관의 이름
- 서명 기관의 서명
- 브라우저가 인증서를 받으면 서명 기관을 검사함. 신뢰해야 할지 확신할 수 없다면 대화 상자를 띄워 사용자에게 물음.
HTTPS의 세부사항
- HTTPS는 HTTP의 가장 유명한 보안 버전임.
- 웹 기반 전자상거래의 고속 성장을 가능하게 함.
- HTTPS는 HTTP 프로토콜에 대칭, 비대칭 인증서 기반 암호 기법의 강력한 집합을 결합한 것임.
- http 스킴을 갖고 있다면, 클라는 서버에 80번 포트로 연결하고 평범한 HTTP 명령을 전송함.
- https 스킴을 갖고 있다면, 클라는 서버에 443번 포트로 연결하고 서버와 바이너리 포맷으로 된 몇몇 SSL 보안 매개변수를 교환하면서 핸드셰이크를 하고, 암호화된 HTTP 명령을 전송함.
- 만약 SSL이 80번 포트로 도착한다면, 잘못된 HTTP로 해석하고 커넥션을 닫음.
- SSL이 보안 서버와 커넥션을 준비하는 방법
- HTTPS에서의 절차는 SSL 보안 계층 때문에 HTTP보다 약간 더 복잡함.
- 클라이언트는 먼저 웹 서버의 443포트로 연결하고 TCP 연결이 되고 나면, 클라이언트와 서버는 암호화를 어떤 방법으로 할지와 교환 키를 협상하면서 SSL 계층을 초기화 함.
- 핸드셰이크가 완료되면 SSL 초기화는 완료되며, 클라이언트는 요청 메시지를 보안 계층에 보낼 수 있음.
- 이 메시지는 TCP에 보내지기 전에 암호화 됨.
- SSL 핸드셰이크에서는 다음과 같은 일이 일어남.
- 프로토콜 버전 번호 교환
- 양쪽이 알고 있는 암호 선택
- 양쪽의 신원을 입증
- 채널을 암호화하기 위한 임시 세션 키 생성
- 서버 인증서
- 오늘날, 클라이언트 인증서는 웹 브라우징에선 흔히 쓰이지 않음. 대부분의 사용자는 개인 클라이언트 인증서를 갖고 있지도 않음.
- 한편, 보안 HTTPS 트랜잭션은 항상 서버 인증서를 요함. 서버를 얼마나 신뢰할 수 있는지 평가하는 것임.
- 서버 인증서는 조직의 이름, 주소, 서버 DNS 도메인 이름, 그리고 그 외의 정보를 보여주는 X.509 v3에서 파생된 인증서다.
- 사이트 인증서를 검사하는 과정은 날짜 검사, 서명자 신뢰도 검사, 서명 검사, 사이트 신원 검사를 포함함.
- 하나의 서버에 여러 호스트(가상 호스트)로 운영되면 까다로울 수 있음.
진짜 HTTPS 클라이언트
- SSL은 복잡한 바이너리 프로토콜임.
- SSL을 쉽게 만들어주는 상용 혹은 오픈 소스 라이브러리들이 존재함.
- OpenSSL
- SSL, TLS의 가장 인기 있는 오픈 소스임.
프락시를 통한 보안 트래픽 터널링
- 클라는 종종 웹 프락시 서버를 이용함.
- 그러나 클라가 서버로 보낼 데이터를 서버의 공개키로 암호화하면 프락시는 더 이상 HTTP 헤더를 읽을 수 없음.
- 프락시가 HTTP 헤더를 읽을 수 없다면, 프락시는 요청을 어디로 보내야 하는지 알 수 없게 됨.
- 이 때 HTTPS SSL 터널링 프로토콜을 사용함. HTTP는 CONNECT라는 확장 메서드를 사용하여 어디로 갈지 명시함.
CONNECT home.netscape.com:443 HTTP/1.0 User-agent: Mozilla/1.1N
- 프락시는 이 CONNECT 메서드를 받으면 직접 대상으로 연결시켜주는 터널을 만들어 줌.