네트워크 보안 Ch.9 Network Security

TLS(transport layer security)

PC에서 실제로 사용되고 있는 네트워크 프로토콜. 인터넷 상에서 정보를 암호화해서, 인터넷 상에서 정보를 주고받을 때 사용하는 보안 프로토콜이다.

• 1994년에는 SSL이라는 이름으로 먼저 제안이 됐고 그래서 94년에 이제 netscape에서 96년까지 버전 3.0까지 발표를 했다.
• 3.0 이후 부터 TLS로 표준화가 됐다. SSL은 예전에 쓰였던 이름이고 TLS가 지금 쓰이는 이름이라고 보면 된다. 그래서 혼용돼서 많이 사용이 된다.
• ssl은 Secure Sockets Layer라는 뜻이고 tls는 transport layer security인데 혼용돼서 사용된다. 같은 건데 버전의 차이만 있는 것이다.
• 지금까지 배웠던 암호화 그리고 ca, 인증서, pki 등의 총집합체. 배웠던 것들이 다 적용된 프로토콜이다.
• 비대칭 키를 암호화를 사용해서 대칭 키를 나누는 프로토콜을 짠 게 바로 TLS이다.

왜 복잡하게, 하나만 쓰지, 대칭키랑 비대칭 키를 나눠서 쓸까?

• 대칭키는 빠르고 효율적이지만 처음에 나눠 갖는 게 애매하다. 하지만 잘 나눠서 세션키로 사용하면 가장 효율적이다.
• 비대칭키는 서로 주고받는 것이 안전하다. (디피헬먼, 엘리틱 커브 등) 하지만 속도가 느리다.
• 계속 서버와 통신을 주고 받기 위해서는 대칭키가 유리해서, 대칭키를 쓰기 위해 대칭키를 처음 나눠 갖는 과정을 비대칭키 암호화를 이용한다. 비대칭키를 나눠 갖는 방법을 정한 것이 TLS 프로토콜이다. 비대칭키를 통해서 키를 나누고, 나눈 키를 가지고 앞으로 어떻게 두 개가 커뮤니케이션을 할 건지에 대해서 정의하고 있다. https를 지원하기 위해서 만든 프로토콜이다. IETF(국제 인터넷 표준화 기구)에도 인정을 받은 프로토콜이다.

역사

• ssl 1.0 : 일반인들에게 공개되지 않음.
• ssl 2.0 : 제안됐지만 결함이 존재했다.
• ssl 3.0 : 개선되어서 나왔다.
  그 이후 TLS가 선언되었고 이후로 계속 개선되어 나오고 있다. 최근 2008년까진 TLS 1.2가 많이 사용되었고, 최근에는 TLS 1.3으로 거의 교체되어 사용되고 있다. TLS 1.3은 좀 더 효율적이고, 좀 더 안전하며 1.2보다 약 두 배 빠르다. RFC 문서에 명시되어 있다.

What is TLS?

tls 프로토콜은 일반적으로 일단 모든 종류의 인터넷 트래픽을 암호화한다. 대표적으로 웹 트래픽을 암호화를 하는 데 사용된다. TLS는 SSL 3.0 이후 버전하고 호환되지 않는다. 즉, 현재 TLS 1.2 이상 버전을 무조건 강조하고 있다.

TLS가 보장하는 것

• authentication
• confidentiality
• integrity

우리가 아마존에서 책을 살 때, 아마존과 통신하고 있는게 맞는지(authentication) 확인해야 하고, 내 신용카드와 정보들이 보호되고 변경되지 않아야 한다 (confidentiality and integrity). 이를 보장하기 위해서 TLS를 사용한다.

TLS는 브라우저가 접속하려고 하는 웹페이지, 모바일 앱에 표시되는 데이터, 내가 제출한 민감한 정보나 양식들과 같은 데이터들을 보호한다. 전송레벨에서 보안은 confidentiality, integrity, authentication을 요구한다.

• 기밀성(confidentiality) - 클라이언트와 서버 사이의 송신되는 데이터는 그 둘만 읽을 수 있어야 한다.
• 무결성(Integrity) - 클라이언트와 서버 사이의 데이터 오류와 위변조 신호가 발생할 경우 감지되어야 한다.
• 인가 (Authentiaction) - 클라이언트나 서버, 혹은 둘 다 통신 대상이 맞는지 확인해야 한다.

TLS는 전송 계층의 TCP 레이어 위에 존재한다. TCP 계층은 데이터를 받아서 패킷을 컴파일해서 다시 TCP 계층으로 보내주는, 패킷 단위로 묶어서 보내고 받는 역할을 하는 계층인데, 이 위에서 동작을 하고 있다. 그리고 그 위에 http, ftp, smtp가 동작을 하고 있다. 그래서 우리가 https를 사용할 수 있게 끔 선언할 수 있다.

TLS의 실제 동작 (가장 핵심)

Cipher suite negotiation, authentication, key exchange 이 세 개의 메커니즘을 기반으로 한다.

• Cipher suite negotiation : 어떤 암호화를 사용할지 서로 협상하는 과정
• Authentication - 서로 맞는지 확인하는 과정.
• Key exchange - 키를 나눠 갖는 과정.

이 세 가지가 TLS Handshake 가장 기본적인 동작이다.

아주 단순화 된 프로토콜.

앞으로의 대화는 K로 암호화되기 때문에 데이터의 무결성이 보장된다. 그렇다면 위의 프로토콜은 완벽할까?

아니다! 클라이언트 입장에서 서버가 그 서버가 맞는지 확인할 방법은 없다. 하지만 대칭키 K는 보호된다. 서버가 맞지 않다면 열 수 없기 때문이다. 그러나 이 프로토콜 상에서 서버가 원하는 서버가 맞는지 확인할 수 있는 방법은 없다. 마찬가지로 서버 입장에서도 클라이언트가 맞는지 인증되지 않는다. 하지만 서버 입장에서 클라이언트가 맞는지 확인하는 것은 중요치 않기 때문에 넘어간다.

즉, 클라이언트가 자신이 통신하고 있는 서버가 그 서버가 맞는지 확신할 수 없다는 것이 문제이다.

실제 TLS 의 동작 과정

1. Cipher suite negotiation

Cipher suite : 암호화 기능과 기술의 총 모음. 모든 암호화 메커니즘들이 들어있다. ECDHE | ECDSA |… 와 같이 리스트들이 들어있다. 리스트를 보고 어떤 것을 암호화에 사용할지 선택한다.

Cipher suite : TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Cipher suite : TLS_AES_128_GCM_SHA256
Cipher suite : TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
...

위처럼 여러가지 조합의 Cipher suite가 들어있다. 이 중에서 골라서 사용한다.

TLS Handshake - 데이터를 암호화해서 주고받기 위해 서버와 클라이언트가 서로 협의하는 과정

2. Authentication

• 두가지 유형의 디지털 서명 기반 방법을 사용한다. RSA, ECDSA를 사용한다.
• ECC와 RSA를 비교했을 때, ECC가 훨씬 효율적이다. ECC에서 160비트로 RSA에서 1024비트의 효과를 낼 수 있다.

3. Key Exchange

• 두가지 타입을 기반으로 한다. RSA와 DH(디피헬먼)을 사용한다.
• RSA의 경우 TLS 1.3 버전에서 삭제됐다. DH만 현재 키 교환에서 사용되고 있다.
• PRF(수도 랜덤 함수)와 HKDF(HMAC기반의 추출 확장 키 유도 함수)를 사용한다. 둘을 연산에 사용해 암호키를 유도해낸다. 프리마스터키를 가지고 키를 최종적으로 계산할 때 사용한다. 계산 후 서버와 클라이언트는 동일한 세션 키를 가지게 된다. 이 때 날리는 메세지가 ChangeCipherSpec이다. Finished는 위에서 봤던 것처럼 자신의 입장에서 계산이 끝났다는 것을 알리는 메세지이다. 서로 준비되었다는 것을 알릴 때 사용한다.

---

RSA 키교환 메커니즘

• 소인수 분해를 이용한 메커니즘.
• PFS가 보장이 안된다는 치명적인 단점이 존재한다. PFS(Perfect Forward Secrecy). 대화 내용을 기록했다가 나중에 알아낼 수 있다. DH도 PFS가 보장되지 않는다 -> 1회성 DH를 사용한다(Ephermeral DH). PFS는 완전 순방향 비밀성을 보장하기 위해서 필요하다. RSA의 경우 이러한 한계점이 있다.

DH 키교환 메커니즘.

-Ephermeral DH : 1회성 DH. 각 세션 마다 무조건 서로 다른 value를 사용하게끔 해 사용한 것은 까먹도록 한다. PFS를 보장한다.

• TLS1.3 의 경우부터 고정된 특정한 DH 파라미터와 Ephemeral 모드의 사용만 지원하고 있다.

---

TLS 1.2

다소 비효율적이다. TLS 과정에 총 136ms가 소요된다. 다소 오래걸린다는 단점이 있다.

TLS 1.3

1.2의 취약점과 단점을 보완해서 나온것이 TLS 1.3이다. 더 빠른 속도와 더 휼륭한 보안성을 제공한다.

• 구식 암호화 알고리즘과 메커니즘을 제거했다.
• RSA 키 교환을 제거했고, 무조건적으로 PFS 보장하게 했다. (DHE 혹은 ECDHE만 사용하게 한다.)
• Negotiation handshake 횟수를 줄였다. (Premaster key를 보내는 과정을 줄여서 최소화 시켰다.)
• Cipher suite에 적용하는 알고리즘 수를 줄였다. 블록 암호화를 없애고 AEAD bulk encryption 이런 확장형 블록 암호화를 적용하도록 했다.
• 암호화를 추출하고 키를 유도하는 메커니즘도 HKDF를 사용하도록 했다.
• 전체 handshake를 서명하도록 만들어 보안성을 높였다.
• 새로운 twisted Edward 곡선 암호화 메커니즘을 적용했다.
• TLS 1.2의 경우 roundtrip이 2번 이었지만, TLS 1.3은 절반으로 줄여 1번의 roundtrip이다. 한 번의 roundtrip만으로 키를 교환하고 커뮤니케이션 준비과정을 마치도록 디자인 했다.
• 기존에는 모든 조합에 대해서 세트별로 나열이 되어있었는데, 조합을 만드는게 아니라 암호는 암호, 키는 키, 인증서는 인증서대로 각각 묶어서 선택하는 방식으로 변경했다. 즉 키교환 리스트, 암호화 리스트, 인증서 리스트를 보낸 다음 각 리스트마다 하나씩 고르도록 했다. 훨씬 효율적으로 변했다. 예전의 경우 새로운 프로토콜이 추가 되면 새롭게 조합을 다시 만들어서 계산해서 넣어야 했는데 지금은 그럴 필요없이 하나만 끼워넣어 추가시키면 된다.

예전 : A1가, A2가, A3가, A1나, A2나, A3나, B1가, B2가, B3가, B1나, B2나, B3나
지금 : (A,B) / (1, 2, 3) / (가, 나). 각 리스트 중 하나씩 뽑아서 선택.

---

FREAK

• TLS 1.2 같은 경우, 서버 자체의 서명은 2번에만 해당했다. 다른 부분은 서명되지 않았다. 그래서 다운 그레이드 어택에 취약점이 존재했다.

중간자가 cipher suite negotiation을 할 때 임의로 제약을 걸어서(수출용 암호화), 약한 암호화 방식을 사용하도록 만든다. 수출용 암호화의 경우 40비트를 사용하기 때문에, 2의 40승 밖에 되지 않아 브루트 포스 방법으로 뚫을 수 있다.

•  

즉 중간자가 인위적으로 약한 암호화를 쓰도록 하는 공격이다. 약한 암호화를 이용해 키를 알아내고, 메세지를 하이재킹하거나 속여서 메세지를 보내는 공격등을 한다.

• FREAK을 막기 위해서 TLS 1.3에서는 모든 과정을 서명하고 있다. 전체 handshake 과정에서 서명을 하게 된다. 따라서 중간자가 껴서 cipher suite를 바꾼다든가 하는 공격을 할 수 없다.

정리 : TLS 1.2 버전에서는 클라이언트 헬로에 대한 인증 절차가 없었다. 따라서 중간자가 껴서 속여서 보내더라도 서버가 변경된 메세지인지 알 수 없었다. 그리하여 FREAK 공격이 가능했는데, TLS 1.3 버전 부터는 처음부터 서명을 넣어서 보낸다. 서명을 비교해서 무결성을 확인할 수 있다.

---

CA and PKI

TLS에서 인증서, 그 서버가 맞는지 확인하는 과정이 필요했다. 이 인증서를 이용하기 위해선, 인증기관에서 인증서를 발급하고 거기에 맞는 공개키를 제공하는 절차가 먼저 이루어졌어야 한다.

실제로 CA로 부터 인증서를 발급받는 절차

지은닷컴이라는 사이트를 만들었다.

이 웹사이트에 대한 정보와 공개키를 만들기 위한 코드 CSR(Certificate Signing Request)가 필요하다. CSR은 CA에 인증서를 요청할 때, 인증 기관에 제출하는 요청이다. 인증기관에 신청하기 위해선 TLS와 같은 프로토콜에 사용되는 키 페어, 공개키와 비밀키를 생성해야 한다. 그리고 그 키를 CSR에 넣어서 도메인 이름, 호스트 이름, 국가, 회사 같은 정보와 묶어서 보낸다. CA는 이것을 받아서 확인을 한다.

신뢰성, 안전성 검사가 끊나면 그 사이트에 대한 공개키를 생성을 해서, 인증기관이 가지고 있는 개인키로 암호화 시킨다. 그렇게 해서 만든게 인증서이다. 인증 기관의 개인키로 서명되어 있기 때문에 인증기관에서 보증한 것이다. 인증서 내부에는 공개키에 대한 내용과 CSR에 대한 내용들이 암호화돼서 들어가 있다.

인증 기관도 조종당할 수 있다. 따라서 인증서를 100% 신뢰할 수 있지는 않다. 여태까지 나온 것들은 개방형 PKI 형식이다. 이걸 믿을 수 없어서 나온게 폐쇄형 PKI이다. 외부에서 공격할 가능성이 있는 서비스를 구축하는 경우, 일부 조직안에서만 실행되는 CA를 구축을 해서 PKI자체를 폐쇄 상태로 유지하는 것이 폐쇄형 PKI이다. 컨셉츄얼한 개념이고 사실상 현재 사용되는건 전부 OPEN PKI 형태이다.

인증서의 문제들

• 파이어 폭스에서 인증서를 삭제하면, 다시 생성된다.
• 윈도우를 감시할 수 있다..(?)
• 사용자들이 인증서 경고를 무시한다.

심각한 문제

CA에서 인증서를 발급할 때 철저하게 검증하지 않는다.

• 인증 취소 재발급의 문제가 있다. (certification revocation matters). CRL이라고 하는 인증서 해지 목록이 있다. 주기적으로 업데이트가 되는데, 업데이트되는 주기가 일정하지 않을 수도 있다. CRL은 점점 커지기만 하고 그리고 업데이트가 제대로 안 됐을 수도 있다는 문제가 있다. 즉, 사용자 입장에서 속도가 느려지게 된다. 주기적인 업데이트 기간 사이에 없어지는 인증서에 대한 반영이 느릴 수 있다.
• 이를 해결하기 위해서 나온것이 OCSP이다. 리스트를 받아서 스캔하는 것이 아니라, 온라인 자체에서 인증서 상태를 유지하는 것이다. CRL은 주기적으로 리스트를 업데이트 해줘야 되는 방식이라면, OSCP의 경우 클라이언트가 서버에 상태요청을 보내면 바로 리스폰스를 준다. 리스트를 가지고 있을 필요 없이 리스폰스를 받아서 유효한지 바로 확인할 수 있는 방식이다. RFC 표준으로 기술되어 있으며 좀 더 효율적인 인증서 폐기 리스트 관리를 위해서 제안되었다.