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

14.1 HTTP를 안전하게 만들기

대량 구매, 은행 업무 등을 위해서는 HTTP와 디지털 암호화 기술을 결합해야 합니다. HTTP는 원래 평문 통신 프로토콜로, 도청이나 데이터 위조에 취약합니다. 따라서 디지털 암호화 기술을 활용하여 HTTP 트랜잭션을 안전하게 보호하는 것이 필수적입니다.

• 서버 인증: 위조된 서버가 아닌 진짜 서버와 이야기하고 있음을 알 수 있어야 합니다. 서버 인증은 웹사이트의 신뢰성을 보장하고, 사용자가 피싱 사이트에 속아 개인 정보를 유출하는 것을 방지합니다.
• 클라이언트 인증: 진짜 사용자와 이야기하고 있음을 알 수 있어야 합니다. 클라이언트 인증은 사용자 계정을 보호하고, 권한 없는 사용자의 접근을 차단합니다.
• 무결성: 데이터가 위조되는 것으로부터 안전해야 합니다. 데이터 무결성은 전송되는 데이터가 중간에 변조되지 않았음을 보장합니다.
• 암호화: 도청 걱정 없이 클라이언트/서버가 대화할 수 있어야 합니다. 암호화는 통신 내용을 제3자가 읽을 수 없도록 보호합니다.
• 효율: 알고리즘이 충분히 빨라야 합니다. 암호화 과정은 통신 속도에 영향을 미치므로, 효율적인 암호화 알고리즘을 사용하는 것이 중요합니다.
• 편재성(ubiquity): 프로토콜이 거의 모든 클라이언트와 서버에서 지원되어야 합니다. HTTPS는 대부분의 웹 브라우저와 웹 서버에서 지원됩니다.
• 관리상 확장성: 누구든 어디서든 즉각적인 보안 통신을 할 수 있어야 합니다. HTTPS는 인증서 발급을 통해 쉽게 보안 통신을 구축할 수 있도록 지원합니다.
• 적응성: 현재 알려진 최선의 보안 방법을 지원해야 합니다. HTTPS는 SSL/TLS 프로토콜을 사용하여 보안 통신을 제공하며, 새로운 보안 취약점이 발견되면 업데이트를 통해 대응할 수 있습니다
• 사회적 생존성: 사회의 문화적, 정치적 요구를 만족시켜야 합니다.

14.1.1 HTTPS

HTTPS는 HTTP의 보안 취약점을 해결하기 위해 개발된 프로토콜입니다. HTTPS는 HTTP 하부에 SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security)라는 보안 계층을 추가하여 통신 내용을 암호화합니다. 이를 통해 데이터의 기밀성, 무결성, 인증을 보장하여 안전한 웹 환경을 구축할 수 있습니다. HTTPS는 웹 주소 앞에 https://를 붙여서 사용하며, 일반적인 HTTP 통신과는 다른 포트(443)를 사용합니다.

14.2 디지털 암호학

14.2.1 비밀 코드의 기술과 과학

암호법은 메시지 인코딩과 디코딩에 대한 과학이자 기술입니다. 암호법은 고대 이집트 시대부터 존재해 왔으며, 현대에는 컴퓨터 기술과 접목하여 더욱 발전했습니다. 암호법은 군사, 외교, 상업 등 다양한 분야에서 중요한 역할을 수행합니다.

14.2.2 암호

암호란 메시지를 인코딩하는 어떤 특정한 방법과 나중에 그 비밀 메시지를 디코딩하는 방법입니다. 원본 메시지 평문에 암호가 적용된 메시지를 암호문이라고 합니다. 암호화는 평문을 암호문으로 변환하는 과정이며, 복호화는 암호문을 평문으로 되돌리는 과정입니다.

14.2.3 암호 기계

처음에는 간단한 암호 알고리즘으로 시작하여 기술이 진보하면서 인코딩/디코딩하는 기계를 만들기 시작했습니다.

대표적인 암호 기계로는 제2차 세계대전 때 사용된 독일군의 에니그마(Enigma)가 있습니다. 에니그마는 복잡한 기계 장치를 이용하여 암호문을 생성했으며, 연합군은 에니그마 암호를 해독하기 위해 많은 노력을 기울였습니다.

14.2.4 키가 있는 암호

올바른 키 없이는 디코더가 동작하지 않습니다. 이러한 키는 하나의 암호 기계를 여러 가상 암호 기계 집합처럼 만들어줍니다. 오늘날 거의 대부분의 암호 알고리즘은 키를 사용합니다. 키는 암호화와 복호화 과정에서 사용되는 비밀 정보이며, 키의 길이에 따라 암호의 강도가 결정됩니다. 키가 길수록 가능한 키 값의 개수가 많아지므로, 암호를 해독하기가 어려워집니다.

14.2.5 디지털 암호

디지털 계산이 도래하면서 복잡한 인코딩과 디코딩 알고리즘이 가능해졌습니다. 매우 큰 키를 지원하는 것이 가능해져 키 값마다 다른 가상 알고리즘을 만들어낼 수 있게 되었습니다. 키가 길수록 인코딩의 많은 조합이 가능해져 무작위로 추측한 키에 대한 크래킹이 어려워집니다.

14.3 대칭키 암호법

많은 암호 알고리즘은 대칭키 암호인데, 인코딩할 때 사용하는 키가 디코딩을 할 때와 같습니다. 발송자와 수신자 모두 동일한 비밀키를 공유하고 암호화 후 해독하기 위해 공유된 키를 사용합니다. 대칭키 암호는 암호화 속도가 빠르다는 장점이 있지만, 키를 안전하게 공유해야 한다는 단점이 있습니다. 대표적인 대칭키 암호 알고리즘으로는 AES, DES, RC4 등이 있습니다.

14.3.1 키 길이와 열거 공격

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

가능한 키 값의 개수는 키가 몇 비트이며 얼마나 많은 키가 유효한지에 달려 있습니다.

128비트 키를 사용한 대칭키 암호는 매우 강력한 것으로 간주됩니다.

14.3.2 공유키 발급하기

대칭키 암호의 단점 중 하나는 발송자와 수신자가 서로 대화하려면 둘 다 공유키를 가져야 한다는 것입니다. 공용 웹사이트에서 모든 손님의 키를 생성하고 기억해야 합니다. 관리해야 하는 사람 입장에서 지옥입니다. 이러한 대칭키 암호의 키 분배 문제를 해결하기 위해 공개키 암호 방식이 개발되었습니다.

14.4 공개키 암호법

두 개의 비대칭 키를 사용하여, 하나는 메시지를 인코딩하고 하나는 메시지를 디코딩하기 위해 사용합니다. 인코딩 키는 모두에 의해 공개되어 있지만 호스트만이 개인 디코딩 키를 가지고 있습니다. 키를 분리하기 때문에 메시지의 인코딩은 누구나 할 수 있지만 디코딩은 소유자만 할 수 있도록 합니다.

14.4.1 RSA

공개키나 암호문의 일부를 알고 있다 해도 개인 키를 계산할 수 없습니다. 이 중 가장 상용화된 RSA 알고리즘이 가장 유명합니다.

RSA 암호는 소인수분해의 어려움을 이용하여 안전성을 확보합니다.

14.4.2 혼성 암호 체계와 세션 키

공개 키 암호 방식은 계산이 느린 경향이 있습니다. 그래서 실제로는 대칭과 비대칭 방식을 섞은 것이 사용됩니다. 따라서 노드들 사이에 안전한 의사소통 채널을 수립할 때는 편리하게 공개 키 암호를 사용하고 이렇게 만들어진 채널을 통해서 임시의 무작위 대칭 키를 생성하고 교환하여 이후 나머지 데이터를 암호화할 때는 빠른 대칭 키를 사용하는 방식이 흔히 쓰입니다.

14.5 디지털 서명

디지털 서명은 인터넷 보안 인증서에서 중요하게 쓰이는 것으로, 누가 메시지를 썼는지 알려주고 메시지가 위조되지 않았음을 증명하기 위해 서명을 하도록 하는 데에 이용될 수 있습니다.

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

저자만이 개인 키를 가지고 있어 체크섬을 계산할 수 있습니다. 체크섬은 저자의 개인 서명처럼 동작합니다. 서명은 메시지 위조를 방지합니다. 메시지를 수정하면 체크섬이 맞지 않기 때문입니다. 디지털 서명은 비대칭 공개키에 의해 보통 생성되고, 개인 키는 소유자만이 알고 있기 때문에 일종의 지문처럼 사용됩니다.

14.6 디지털 인증서

14.6.1 인증서의 내부

대상의 이름, 유효 기간, 인증서 발급자, 디지털 서명, 사용된 서명 알고리즘에 대한 서술적인 정보뿐 아니라 대상의 공개키도 담고 있습니다.

14.6.2 X.509 v3 인증서

오늘날 사용되는 대부분의 인증서입니다. X.509 v3 인증서는 다양한 확장 기능을 제공하며, 웹 보안, 이메일 보안 등 다양한 분야에서 사용됩니다.

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

최신 브라우저는 자동으로 접속한 서버에서 디지털 인증서를 가져옵니다. 서버 인증서는 웹 사이트의 이름과 호스트명, 공개키, 서명 기관의 이름, 서명 과 같은 필드를 갖고 있습니다. 브라우저는 인증서에서 서명 기관을 검사하여 신뢰할만한 서명 기관이라면 이미 알고 있는 공개키로 그 서명을 검증합니다. 모르는 곳의 서명 기관이라면 신뢰해야 할지 대화 상자로 보여줍니다.

14.7 HTTPS의 세부사항

HTTPS는 HTTP의 가장 유명한 보안 버전으로 HTTP 프로토콜에 대칭, 비대칭 인증서 기반 암호 기법의 강력한 집합을 결합한 것입니다.

14.7.1 HTTPS 개요

보안 전송 계층을 통해 전송되는 HTTP로 TCP로 보내기 전에 먼저 그것들을 암호화하는 보안 계층으로 보냅니다. 오늘날의 HTTPS의 보안 계층은 SSL과 현대적 대체품인 TLS로 구현되었습니다.

14.7.2 HTTPS 스킴

클라이언트는 http 스킴의 url일 경우에는 80번 포트로 연결하고 평범한 http 명령을 전송합니다. https 스킴을 가진다면 443 포트로 연결하고 바이너리 포맷으로 ssl 보안 매개변수를 교환하면서 핸드셰이크 합니다.

14.7.3 보안 전송 셋업

클라이언트는 웹 서버와 443 포트로 연결하고 암호법 매개변수와 교환 키를 협상하면서 SSL 계층을 초기화합니다. 핸드셰이크가 완료되면 SSL 초기화가 완료되고 요청 메시지를 보안 계층에 보낼 수 있습니다.

14.7.4 SSL 핸드셰이크

SSL/TLS 핸드셰이크는 클라이언트와 서버가 서로를 인증하고, 안전한 통신을 위한 세션 키를 공유하는 과정입니다. 핸드셰이크에서는 다음과 같은 일이 일어납니다.

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

 

1. 클라이언트와 서버는 서로가 지원하는 암호화 방식과 프로토콜 버전을 교환합니다.
2. 서버는 자신의 인증서를 클라이언트에게 보냅니다.
3. 클라이언트는 인증서를 확인하고, 서버의 공개 키를 얻습니다.
4. 클라이언트는 무작위로 생성한 '세션 키'를 서버의 공개 키로 암호화하여 서버에게 보냅니다.
5. 서버는 자신의 개인 키로 세션 키를 해독합니다.
6. 클라이언트와 서버는 세션 키를 사용하여 데이터를 암호화하고 통신합니다.

 

14.7.5 서버 인증서

SSL은 서버 인증서와 클라이언트 인증서 즉 상호 인증을 지원합니다. 대부분의 사용자는 개인 클라이언트 인증서를 갖고 있지 않고, 웹 서버도 클라이언트 인증서를 요구하는 일이 별로 없습니다. 보안 HTTPS 트랜잭션은 항상 서버 인증서를 요구합니다. 서버 인증서는 개인 정보를 보내기 전에 그 서버를 얼마나 신뢰할 수 있는지 평가하는 것을 도와줄 것입니다.

14.7.6 사이트 인증서 검사

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

 

 

• 날짜 검사: 인증서가 유효함을 확인하기 위해 시작 및 종료일을 검사합니다. 인증서가 만료되었거나 아직 유효하지 않은 경우, 웹 브라우저는 사용자에게 경고 메시지를 표시합니다.
• 서명자 신뢰도 검사: 알려져 있지 않은 인증기관으로부터 서명된 인증서를 받았다면 경고를 보여줍니다. 웹 브라우저는 미리 등록된 신뢰할 수 있는 인증 기관 목록을 가지고 있으며, 이 목록에 없는 인증 기관에서 발급된 인증서는 신뢰할 수 없는 것으로 간주합니다.
• 서명 검사: 서명기관의 공개키를 서명에 적용하여 체크섬과 비교해봄으로써 무결성을 검사합니다. 디지털 서명은 메시지의 위변조 여부를 확인하는 데 사용되며, 서명 검사를 통해 인증서가 변조되지 않았음을 확인할 수 있습니다.
• 사이트 신원 검사: 다른 인증서를 복사하거나 트래픽을 가로채는 것을 방지하기 위해 인증서의 도메인 이름이 서버의 도메인 이름과 맞는지 검사합니다. 웹 브라우저는 인증서에 포함된 도메인 이름과 사용자가 접속한 웹사이트의 도메인 이름을 비교하여 일치하는지 확인합니다.

 

14.7.7 가상 호스팅과 인증서

가상 호스트로 운영되는 사이트는 맞지 않는 호스트명에 도착했다면 경고 상자가 나타날 것입니다. 이러한 문제를 피하기 위해 도메인 소유자는 보안 트랜잭션을 시작하여 맞는 도메인으로 리다이렉트합니다. 가상 호스팅되는 사이트의 인증서 관리는 다소 까다로울 수 있습니다.

14.8 진짜 HTTPS 클라이언트

14.8.1 OpenSSL

SSL과 TLS의 가장 인기 있는 오픈 소스 구현입니다. OpenSSL은 C 언어로 작성되었으며, 다양한 운영체제에서 사용할 수 있습니다. OpenSSL은 웹 서버, 웹 브라우저, 이메일 클라이언트 등 다양한 응용 프로그램에서 사용됩니다.

14.8.2 간단한 HTTPS 클라이언트

서버와 SSL 커넥션을 맺고 신원 정보를 출력하고 보안 채널을 통해 http 요청을 보내고 응답을 받습니다.

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

클라이언트가 서버로 데이터를 전송할 때, 프락시 서버를 거쳐 데이터를 주고받는 경우가 있습니다. 이때, HTTPS를 사용하면 데이터는 암호화되어 전송되지만, 프락시 서버는 암호화된 데이터를 그대로 전달하기 때문에 내용을 확인할 수 없습니다.

 

HTTPS 터널링은 클라이언트가 프락시 서버를 통해 특정 서버에 안전하게 접속하는 기술입니다. 클라이언트는 프락시 서버에 접속하면서 연결하고자 하는 서버의 주소를 함께 전달합니다. 프락시 서버는 이 정보를 이용하여 서버와 연결하고, 이후에는 클라이언트와 서버 간의 통신을 중계합니다. 이때, 모든 데이터는 암호화된 상태로 프락시 서버를 통과합니다.

 

HTTPS 터널링 과정

1. 클라이언트는 프락시 서버에 CONNECT 메서드를 사용하여 연결을 요청합니다. 이때, 연결하고자 하는 서버의 호스트명과 포트 번호를 함께 전달합니다.
2. 프락시 서버는 클라이언트가 요청한 서버와 TCP 연결을 맺습니다.
3. 프락시 서버는 클라이언트에게 연결이 성공했음을 알립니다.
4. 이후 클라이언트와 서버는 HTTPS 통신을 시작합니다. 이때, 모든 데이터는 암호화된 상태로 프락시 서버를 통과합니다.