웹 보안(Web Security) - 1

웹 보안 위협은 인터넷의 근간이 되는 TCP/IP와 웹 프로토콜인 HTTP가 데이터에 대한 보안서비스를 제공하지 않는데서 비롯된다.

 

웹 트래픽 보안 방법

웹 보안을 제공하는 한 가지 방법은 IP 보안(IPSec)을 사용하는 것이다. IPSec을 사용할 경우 종단 사용자의 응용에 투명성을 제공해주고 범용 해결책을 제시해준다.

IPSec은 필터링 기능을 가지고 있어서 오직 선별된 트래픽에서만 IP 보안 처리를 하기 때문에 이에 대한 오버헤드만 추가된다.

또 다른 범용 해결책은 TCP 바로 위에서 보안을 구현하는 것이다. 이 방법의 가장 좋은 예는 안전 소켓 계층(SSL, Secure Socket Layer)과 전송 계층 보안(TLS, Transport Layer Security)라고 알려진 그 후속 인터넷 표준이다.

 

하이퍼텍스트 전송 프로토콜(HTTP, Hypertext Transfer Protocol)

HTTP는 웹에서 웹페이지를 가져오기 위해 어떻게 클라이언트-서버 프로그램이 작성될 수 있는지를 정의하는데 사용된다.

HTTP 클라이언트는 요청을 하고 HTTP 서버는 응답을 한다. 서버는 포트 80번을 사용하고 클라이언트는 임시 포트 번호를 사용한다.

 

영속성

HTTP 버전 1.0은 비영속적 연결을 사용하였으나 1.1은 영속적 연결을 기본값으로 하는데 이는 사용자에 의해 변경될 수 있다.

 

- 비영속적 연결

비영속적 연결에서는 각 요구/응답에 대해 하나의 TCP 연결이 만들어진다. 이런 전략에서의 동작은 아래와 같다.

· 클라이언트가 TCP 연결을 열고 요청을 보낸다.

· 서버는 응답을 보내고 연결을 닫는다.

· 클라이언트는 EOF 표시가 나타날 때까지 데이터를 읽고 그 후 연결을 닫는다.

비영속적 연결은 서버에 큰 오버헤드를 부과하게 되는데, 그 이유는 서버가 연결을 열 때마다 다른 버퍼들을 필요로 하기 때문이다.

 

- 영속적 연결

영속적 연결에서 서버는 응답을 전송한 후에 차후의 요청을 위해 연결을 열어 놓은 상태로 유지한다. 서버는 클라이언트로부터 요청을 받거나 타임아웃이 되면 연결을 닫을 수 있다.

HTTP/1.1 버전부터 Connection 헤더에 Keep-Alive 옵션이 추가되었다. 이는 TCP 연결 상태를 웹 서버 설정에 따라 일정시간 지속시키는 옵션으로 한 번의 연결 이후에 요청/응답을 반복할 수 있다.

 

HTTP 트랜잭션

HTTP는 TCP 서비스를 이용하지만 HTTP 자체는 stateless 프로토콜이다. 이는 클라이언트에 대한 정보가 서버에 저장되어 있지 않다는 의미이다.

클라이언트는 요청 메시지를 보내어 트랜잭션을 초기화한다. 서버는 응답을 보내어 대답한다.

 

- 요청 메시지

① 요청 라인

요청 메시지의 첫 줄은 요청 라인이라 부른다. 이 라인에는 문자 구분 기호에 의해 분리된 세 개의 필드가 존재한다.

이 필드들은 메소드와 URL, 버전이라 부른다. 이 세 필드는 공백 문자(sp)로 구분되어야 한다. 메소드 필드는 요청 유형을 정의한다.

 

② 메소드

· GET 방식

GET 방식은 가장 일반적인 HTTP Request 형태로 웹 브라우저에 요청 데이터에 대한 인수를 URL(Uniform Resource Locator)을 통해 전송한다.

GET 방식에서는 각 이름과 값을 &로 결합하며 글자수는 255자로 제한된다. URL을 클릭하여 특정 웹 페이지를 똑같이 확인할 수 있는 경우가 GET 방식이 사용된 예이다.

GET 방식은 데이터가 주소 입력란에 표시되기 때문에 최소한의 보안도 유지되지 않는 매우 취약한 방식이다. 따라서 간혹 아이디나 패스워드가 인수로 저장되어 전달되는 경우도 발생한다.

 

· POST 방식

POST 방식은 URL에 요청 데이터를 전달하지 않고 HTTP 헤더 영역이 아닌 바디 영역에 소켓을 이용하여 데이터를 전송하기 때문에 GET 방식과는 달리 데이터가 주소 입력란에 표시되지 않는다.

GET보다는 조금의 보안성을 가져갈 수 있는 방식이다.

 

+ PUT : POST와 마찬가지로 헤더 및 바디를 포함하여 바디에 컨텐츠 내용을 덧붙여 원격지 서버에 지정한 컨텐츠를 저장하기 위한 목적으로 사용된다. 그러나 이를 악용하여 홈페이지 변조에 사용할 수 있다.

+ DELETE : 클라이언트가 권한이 있다면 서버에서 웹페이지를 제거할 수 있다.

+ OPTIONS : 해당 메소드를 통해 시스템에서 지원되는 메소드 종류를 확인할 수 있다.

 

③ 요청 헤더 라인

요청 라인 이후 0개 이상의 요청 헤더 라인을 가질 수 있다. 각 헤더 라인은 추가적인 정보를 클라이언트에서 서버로 보낸다. 예를 들어, 클라이언트는 특별한 형태로 보내지는 문서를 요청할 수 있다. 각 헤더 라인은 헤더 이름, 콜론, 스페이스, 헤더 값을 가진다.

 

④ 빈 라인(Empty Line)

헤더의 끝을 의미하는 개행이다. 헤더의 개수가 가변이기 때문에 빈 라인을 통해 그 끝을 식별한다.

 

⑤ 본체

보통은 메소드가 PUT이나 POST일 때 송신될 주석이나 웹 사이트에 게시될 파일을 담고 있다. GET 방식일 경우에는 요청 데이터가 없기 때문에 메시지 바디가 없다.

 

- 응답 메시지

① 상태 라인(status line)

응답 메시지의 첫 줄은 상태 라인이라 부른다. 첫 필드는 HTTP 프로토콜의 버전을 의미하고 현재는 1.1이다.

상태 코드 필드는 전에 작성했던 글로 대체한다!

HTTP 상태 코드

 

② 응답 헤더 라인

상태 라인 이후 0개 이상의 응답 헤더 라인을 가질 수 있따. 각 헤더 라인은 서버에서 클라이언트로 추가적인 정보를 보낸다.

예를 들어, 송신자는 문서에 대한 부가 정보를 보낼 수 있다. 각 헤더 라인은 헤더 이름과 콜론, 스페이스 그리고 헤더 값을 가지고 있다.

 

③ 빈 라인

헤더의 끝을 의미하는 개행이다. 헤더의 개수가 가변이기 때문에 빈 라인으로 끝을 식별한다.

 

④ 본체

서버에서 클라이언트로 전송되는 문서를 포함한다. 응답이 오류 메시지가 아니라면 본체가 존재한다.

 

SSL/TLS

SSL/TLS는 클라이언트/서버 환경에서 TCP 기반의 Application에 대한 종단간 보안서비스를 제공하기 위해 만들어진 전송계층 보안 프로토콜이다.

SSL은 Netscape사에서 S-HTTP처럼 웹 보안을 위해서 처음으로 제안되었으며, SSL/TLS는 현재 가장 많이 이용되고 있는 암호 통신 방법이다.

SSL/TLS에서는 대칭키 암호, 공개키 암호, 일방향 해시함수, 메시지 인증코드, 의사난수 생성기, 전자서명을 조합해서 안전한 통신을 수행한다. 또한 SSL/TLS는 암호 스위트를 변경해서 보다 강력한 알고리즘을 사용할 수 있다.

즉, SSL/TLS는 특정 암호기술에 의존하지 않는다. 만약 어느 대칭키 암호가 약하다고 판명되면 그 대칭키 암호를 사용하지 않는 암호 스위트를 선택하면 된다.

 

SSL/TLS 상의 HTTP

웹 브라우저로 신용카드 번호를 보낼 때 신용카드 번호라고 하는 데이터는 클라이언트의 요청으로 서버에게 보내진다. 만약 이 통신이 도청자 이브에 의해 도청되면 신용카드 번호는 이브의 손에 넘어가게 된다.

통신 내용을 암호화해주는 프로토콜로 SSL 혹은 TLS를 이용한다. 그리고 SSL/TLS 상에 HTTP를 올린다.

이것은 프로토콜의 이중구조이다. 이로 인해 HTTP 통신은 암호화되어 도청을 방지할 수 있다.

 

SSL/TLS 보안 서비스

· 기밀성 서비스 : DES, RC4와 같은 대칭키 암호화 알고리즘을 사용하여 제공되며, 이때 사용되는 비밀키는 handshake Protocol을 통해 생성된다.

· 클라이언트와 서버 상호 인증 : 연결 과정에서 서로 간에 신뢰할 수 있도록 인증을 사용하는데, 인증에는 RSA와 같은 비대칭키 암호 알고리즘, DSS와 같은 전자서명 알고리즘과 X.509 공개키 인증서가 사용된다.

· 메시지 무결성 서비스 : 안전한 해시 알고리즘을 사용해서 메시지 인증코드를 만들어 메시지에 포함시키기 때문에 신뢰성 있는 통신이 가능하다.

 

암호 스위트(Cipher suite)

SSL/TLS는 암호기술의 틀을 제공한다. 즉, SSL/TLS에서 사용하는 대칭키 암호, 공개키 암호, 전자서명, 일방향 해시함수 등은 사용하고 있던 암호 기술에 결함이 발견되었을 때 부품과 같이 교환할 수 있다.

그러나 대화하는 클라이언트와 서버가 같은 암호 기술을 사용하지 않으면 통신을 할 수 없어 상호운용성을 확보하기 어려워지기 때문에 뭐든지 자유롭게 고를 수 있는 것은 아니다.

암호 기술의 추천 세트로 SSL/TLS가 규정되어 있다. 이 추천 세트를 암호 스위트라 한다.

 

SSL vs TLS

SSL은 2014년 SSL 3.0 사양에 POODLE 공격이 가능한 취약점이 발견되었다.

TLS는 SSL 3.0을 기초로 해서 IETF가 만든 프로토콜이다. 1999년에 RFC 2246으로서 발표된 TLS 1.0은 SSL 3.1에 해당하는 것이다. 2006년에는 TLS 1.1이 RFC 4346으로 발효되었다.

TLS 1.1에는 대칭 암호 알고리즘으로서 AES가 추가되었다. TLS 1.2에는 인증 암호로 GCM과 CCM 모드를 사용할 수 있게 되었다. HMAC-SHA 256이 추가되고, IDEA와 DES가 삭제되었다. 또한 의사 난수 함수(PRF)를 SHA-256을 이용해 만들게 되었다.

TLS 1.3은 안전하지 않은 오래된 암호화 알고리즘(MD5, SHA-1, SHA-224, RC4, DES, 3DES 등)을 제거시켰고, 연결 설정 시 왕복 시간을 줄이기 위해 0-RTT 모드를 추가시켰다. 또한 서명 알고리즘으로 ECDSA가 기본으로 추가되었다.

 

TLS(Transport Layer Security) 프로토콜

가장 널리 사용하는 보안 서비스 중의 하나가 전송 계층 보안(TLS)이다. 

SSL을 아직 사용하고 있지만 IETF에서 사용 중지를 선언했고, 대부분의 기업에서는 TLS 소프트웨어로 대체하였다.

TLS는 TCP에 의존하는 프로토콜로 구현되는 일반 용도의 서비스이다.

 

TLS 구조

TLS 설계를 할 때 신뢰성 있는 종단간에 안전한 서비스를 제공하기 위해 TCP를 활용한다. TLS는 단일 프로토콜이 아니고 2계층에 걸친 프로토콜이다.

Record Protocol은 운반자이며, 응용 계층으로부터 오는 데이터뿐만 아니라 TLS의 상위 프로토콜로부터 오는 메시지를 전송한다. Record 프로토콜에서 오는 메시지는 보통 TCP인 전송 계층의 페이로드이다.

Handshake 프로토콜은 Record 프로토콜에 대한 보안 매개변수를 제공한다. 암호 집합을 설정하고 키와 보안 매개변수를 제공한다. 또한 필요하다면 클라이언트가 서버에 대해 그리고 서버가 클라이언트에 대해 인증된다.

ChangeCipehrSpec 프로토콜은 암호학적 비밀을 신속하게 보내는 데 사용된다. Alert 프로토콜은 비정상 조건을 알리는데 사용된다.

여기에 더해 OpenSSL 1.0.1에 추가된 Heartbeat 프로토콜이 있다. SSL/TLS에서 매번 연결을 재협상하지 않아도 상호간에 연결 지속 신호를 주고받으면서 통신연결을 유지하게 해주는 기능이다. 프로토콜 개체의 가용성을 모니터링 할 때 사용하는 프로토콜이다.

 

Handshake 프로토콜

SSL에서 가장 복잡한 부분이 핸드셰이크 프로토콜이다. 이 프로토콜을 이용해서 서버와 클라이언트가 서로를 인증하고 암호화 MAC 알고리즘 그리고 TLS 레코드 안에 보낸 데이터를 보호하는데 사용할 암호키를 협상할 수 있다.

핸드셰이크 프로토콜은 모든 응용 데이터를 전송하기 이전에 사용한다.

각 메시지는 다음과 같은 3개의 필드로 구성된다.

· Type(1바이트) :  10개의 메시지 중 하나를 나타낸다.

· Length(3바이트) : 메시지의 길이를 바이트로 나타낸다.

· Content(≥0바이트) : 이 메시지와 연관된 매개변수이다.

 

핸드셰이킹 프로토콜은 4단계로 되어 있다.

- 단계별 세부 내용

ⓛ HelloRequest

서버가 아무 때나 보낼 수 있는 메시지로 클라이언트에게 HelloRequest 메시지를 보내어 협상을 시작하자고 요구하는 메시지이다. 현재 협상이 진행 중이면 클라이언트는 이 메시지를 무시한다.

서버는 HelloRequest를 보내고 이에 대한 Handshake가 끝나지 않은 상태에서 또 다시 HelloRequset를 보내서도 안 된다.

 

② ClientHello

클라이언트는 서버에 처음으로 연결을 시작하거나 HelloRequest 메시지에 대한 응답으로 ClientHello 메시지를 보낸다.

ClientHello 메시지는 세션 식별자, CipherSuite 리스트, 클라이언트가 지원하는 압축 알고리즘 리스트, 클라이언트 SSL 버전, 클라이언트가 생성한 난수를 서버에 전달한다.

 

· random : Replay 공격을 막기 위한 것이다. 또한 master_secret으로부터 key_block을 생성할 때, 입력값에 포함되어서 각각의 연결마다 비밀키를 새롭게 생성할 수 있다.

· session_id : 클라이언트가 처음 세션을 생성할 때(full handshake)는 empty를 전송하고 이미 생성된 세션이 상태를 재사용할 때(abbreviate handshake)는 재사용하고자 하는 세션 ID를 전송한다.

· cipher_suites : CipherSuite 리스트는 키 교환 알고리즘, 암호 알고리즘, MAC 알고리즘을 포함한다. 서버는 그 중 하나의 CipherSuite를 선택하고자 한다. 

 

③ ServerHello

서버는 ClientHello 메시지에 대한 응답으로 ServerHello 메시지를 보낸다. 실패할 경우에는 Handshake Failure Alert 메시지를 보낸다.  ServerHello 메시지는 세션 식별자, 선택한 CipherSuite, 선택한 압축 방법, 서버 SSL 버전, 서버가 생성한 난수를 클라이언트에 전달한다.

· server_version : 서버가 지원하는 SSL/TLS 버전과 ClientHello에서 전송받은 client_version(client가 사용할 수 있는 최상위 버전) 중에 같거나 낮은 버전으로 정한다.

· random : Replay 공격을 막고 key_block을 만들 때 사용된다.

· session_id : 현재 접속 중인 세션 ID이다.

· cipher_suite : 클라이언트로부터 받은 목록 중 하나를 정한다.

 

④ ServerCertificate

서버의 인증이 필요한 경우에 서버는 ServerHello 뒤에 바로 서버의 인증서가 포함된 Certificate을 보내어야 한다. 이 때 서버의 인증서는 선택된 cipher suite의 키 교환 알고리즘에 맞는 타입이어야 한다.

 

⑤ ServerKeyExchange

ServerKeyExchange는 서버의 인증서를 보내지 않아거나 보낸 인증서에 키 교환에 필요한 정보가 부족할 때 전송되는 메시지이다.

 

⑥ CertificateRequest

서버는 자신을 클라이언트에게 인증함과 동시에 클라이언트에게 클라이언트의 인증서를 통한 인증을 요구할 수 있다. 이 메시지는 선택적으로 사용되지만, 사용될 경우 서버와 클라이언트의 상호 인증이 이루어질 수 있다.

 

⑦ ServerHelloDone

서버가 보낼 메시지를 다 보냈음을 알려주는 메시지이다. CertificateRequest 메시지가 선택적으로 사용되기 때문에, 클라이언트는 ServerHelloDone 메시지가 도착할 때까지 기다린다.

 

⑧ ClientCertificate

서버가 클라이언트의 인증서를 요구할 경우 클라이언트가 보내는 메시지이다.

 

⑨ ClientKeyExchange

클라이언트는 세션키를 생성하기 위해 임의의 비밀 정보인 48바이트 pre_master_secret을 생성한다. 그리고 선택된 공개키 알고리즘을 이용하여 pre_master_secret을 서버와 공유하게 된다.

즉 RSA 키 교환 방법을 이용할 경우 pre_master_secret을 암호화하여 전송하고, DH 또는 ECDH를 이용할 경우 pre_master_secret은 Diffie-Hellman 키 교환 알고리즘에 정의된 방식으로 유도된다.

 

⑩ CertificateVerify

클라이언트 인증서의 명백한 확인을 위해서 클라이언트는 핸드셰이크 메시지를 전자서명하여 전송한다.

 

⑪ ChangeCipherSpec, Finished

ChangeCipherSpec은 핸드셰이크 프로토콜에 포함되는 것은 아니고, 이 메시지 이후에 전송되는 메시지는 새롭게 협상된 알고리즘과 키를 이용할 것임을 나타낸다.

 

Finished 메시지는 ChangeCipherSpec 메시지 이후에 전송되며 협상된 알고리즘과 키가 처음으로 적용된다. 상대편에서 이 메시지를 통해 협상한 결과를 확인하게 된다.

서버는 ChangeCipherSpec 메시지와 Finished 메시지를 클라이언트에게 보내고, TLS 핸드셰이크 프로토콜 수행을 마치게 된다. 그러면 연결을 통해 애플리케이션 데이터가 전송되기 시작한다.

 

 

Record 프로토콜부터는 다음 2회차에서 마저 정리!