TLS & HTTPS (1)

TLS

TLS(Transport Layer Security)는 컴퓨터 네트워크에 통신 보안을 제공하기 위해 설계된 암호 프로토콜이다. 이 프로토콜은 TCP/IP 네트워크를 사용하는 통신에 적용되며 통신 과정에서 Transport Layer 종단간 보안과 데이터 무결성을 확보해준다. TLS는 인코딩, 암/복호화 압축 및 코드 변환을 하는 OSI Layer 6에 속한다.

 

 

TLS를 사용하는 대표적인 프로토콜은 HTTPS이다. HTTPS는 HTTP + Secure로 HTTP 내부에서 TLS가 보안통신을 처리한다. TLS 프로토콜이 어떤 방식으로 이루어지는지에 대하여 알아보자.

 

TLS Certificate

TLS Certificate는 트랜잭션 동안 두 party 간의 신뢰를 보장하기 위해 사용된다. 예를 들어 사용자가 Web server에 접근하려고 할 때, TLS certificate는 사용자와 서버 간 커뮤니케이션이 암호화되는 것이 보장된다.

 

통신 과정: 보안 연결 없이 통신

일단 TLS등 보안 연결 없이 통신을 하게 되면 어떤 일이 발생할 수 있는지 알아보자.

 

보안 연결 없이 사용자가 인터넷 뱅킹 애플리케이션에 로그인 한다면, 사용자가 입력한 로그인 정보는 plane text로 전달된다. 이 때 네트워크 트래픽을 스니핑하는 해커가 있다면, 해커는 쉽게 사용자 credential(ID / Password)을 탈취할 수 있어 해킹할 수 있다. 따라서 이 방식은 안전하지 않다. (네트워크는 정글이다..)

 

스니핑을 당하지 않으려면 Credential 정보 등 요청에 대한 정보는 반드시 암호화 되어야 한다.

 

암호화 (Symmetric Encryption)

특정 key를 통해 문자열을 암호화하고, 복호화하는 어떤 암호화 방식이 있다고 하자. key는 기본적으로 임의의 숫자와 알파벳 조합이다. 특정 key를 사용하여 암호화된 데이터는 사람이 쉽게 알아볼 수 없는 문자로 변환된다. 그리고 암호화를 할 때 사용된 key만이 암호화된 문자를 복호화 할 수 있다. 다른 key를 사용하여 (제대로 된) 복호화는 불가능하다. 이러한 암호화 방식을 Symmetric Encryption 이라고 한다.

 

 

그러면 스니핑을 방지하고자 클라이언트와 서버는 특정 암 / 복호화 key를 사용하기로 약속한 후 보안통신을 할 수 있다. key가 없는 해커는 요청을 스니핑해도 암호문을 복호화 할 수 없기 때문에 소용이 없다!

 

 

하지만 이런 방법은 실제로는 사용이 불가능하다. 불가능한 가장 큰 이유는 서버가 사용하는 key의 값을 클라이언트가 알 방법이 없기 때문이다. (불특정 다수 클라이언트와 서버가 특정 Key를 사용하자고 약속을 할 수 없다. 해커도 같이 사용하면 안되니까..)

 

암호화 (Asymmetric Encryption)

Symmetric Encryption은 실제로는 사용 불가능한 암호화 방식이다. 그래서 실제로는 약간 다른 방식의 암호화 방식을 사용한다. Symmetric Encryption 처럼 하나의 key로 암/복호화 하는 방식 대신에 두개의 key pair (private key & public key) 를 사용하여 암/복호화 한다. 이러한 방식을 Asymmetric Encryption이라고 한다.

 

Asymmetric Encryption에서 Private Key는 오직 자신만 가지고 있으며 자신만이 알아야 한다. 반면에 Public Key는 상호 통신하는 모든 상대방이 접근 가능하며 알고 있어야 한다. 핵심은 Public Key로 데이터를 암호화하고, Private Key로 데이터를 복호화한다. 그리고 Public key는 상호 통신하는 모든 상대방과 공유되어야 한다.

 

Public Key 공유 과정

서버와 클라이언트 사이의 Public Key를 공유하는 과정을 간단히 알아보자.

 

1. 일단 먼저 클라이언트는 서버에 접근하기 전에 key pair를 생성한다.
2. 클라이언트는 접근하려는 서버에 public key를 전달한다.
3. 서버는 클라이언트의 public key를 보관한 다음, 클라이언트의 public key로 서버의 public key 암호화하여 전달한다.
4. 클라이언트는 클라이언트의 public key로 암호화된 서버의 public key를 받아서 클라이언트의 private key로 복호화하여 서버의 public key를 보관한다.
5. 서로 상대방의 public key를 알기 때문에 암호화 통신이 가능하다.
   • 클라이언트는 서버에게 보낼 데이터를 서버의 public key를 통해 암호화 한다.
   • 서버는 클라이언트에게 받은 데이터를 서버의 private key를 통해 복호화 한다.
   • 서버는 클라이언트에게 보낼 데이터를 클라이언트의 public key를 통해 암호화 한다.
   • 클라이언트는 서버에게 받은 데이터를 클라이언트의 private key를 통해 복호화 한다.

 

Asymmetric Encryption은 안전한가?

Asymmetric Encryption은 스니핑으로부터 안전하다. 서버와 클라이언트 간 key를 공유하는 과정만 보면 알 수 있듯이 해커가 스니핑으로 얻을 수 있는 것은 클라이언트의 public key와 클라이언트의 public key로 암호화된 서버의 public key 뿐이다.

이 두가지 키는 Public key이며, public key는 상대방에게 보낼 때 암호화하는 용도이다. 해커는 암호화된 데이터를 스니핑하여 복호화를 해야 하는데 Public key로는 복호화가 불가능하기 때문에 스니핑으로부터 안전하다. 그래서 Private key는 안전하게 보관이 되어야 한다.

 

하지만 논리적으로 안전할 뿐, 세상에 사기꾼은 많다. 예를 들어, 실제로 은행 사이트가 https://www.beer1bank.com 인데 어떤 사기꾼이 https://www.beer1bank.net 으로 실제 은행 서버와 UI를 똑같이 해서 만들어서 불특정 다수에게 로그인하라고 메시지를 날려 낚아먹을(?) 수도 있다. 컴퓨터를 잘 모르는 누군가는 이 메시지에 낚여서 로그인을 하게 되면 로그인 정보가 사기꾼의 데이터베이스에 저장되어 사기꾼이 실제 서버로 로그인하여 탈탈 털어갈 수도 있다.

 

그래서 실제로 대상 서버가 신뢰할 수 있는 서버인지 알아야 한다. 물론 세상에 셀 수 없을 정도로 서버가 많아서 우리가 직접 이 서버가 신뢰할 수 없는 서버인지 알 수는 없다. 대신에, 서버가 신뢰할 수 있는 서버인지 확인해주는 곳이 있는데 이것이 바로 CA 이다. 

 

2022.07.16 - [Networking/일반] - TLS & HTTPS (2) CA

TLS & HTTPS (2) CA