[CKA] 39. TLS Basic

Date

2025/01/09

TLS Certificates

사용자가 웹 서버에 액세스하려 할 때 TLS 인증서는 사용자와 서버 사이의 통신이 암호화하고, 서버의 신원을 확인하여 사용자가 신뢰할 수 있는 서버와 연결되도록 한다.

Senario

한 유저가 온라인 뱅킹 앱에 접속할 때 암호화가 있을 때와 없을 때의 시나리오를 살펴보자

Without Secure connectivity

안전한 연결성이 없으면 사용자가 입력한 자격 증명이 일반 텍스트 형식으로 전송된다. 이때 해커가 네트워크 트래픽을 탐지하면(sniffing) 자격증명을 쉽게 추출해 사용자의 은행 계좌를 해킬할 수 있다.

With Secure Connectivity

키를 사용해 데이터를 암호화한다. 키는 기본적으로 임의의 숫자와 알파벳으로 이뤄져 있다. 사용자는 임의의 숫자를 데이터에 추가하고, 이를 인식할 수 없는 형식으로 암호화하여 서버로 데이터를 전송한다. 해커가 네트워크를 탐지하더라도 데이터를 얻을 수는 있지만, 암호화가 되어있어 사용할 수 없다. 하지만 데이터를 받는 서버도 마찬가지이다. 키 없이는 복호화할 수 없기 때문에 키의 사본도 서버에 전송해야 한다. 이때 해커가 가로챌 수 있다는 위험이 있다.

이를 Symmetric Encryption(대칭 암호화)라고 한다. 안전한 암호화 방식이지만 데이터의 암호화와 복호화에 대한 동일한 키를 사용하고, 이 키가 송신자와 수신자 간에 교환되어야 하므로 해커가 키에 접근할 수 있다는 위험이 있다.

Asymmetric Encryption

비대칭 암호화는 데이터를 암호화하고 복호화하는 데 단일키를 사용하는 대신, 개인 키(private key)와 공개 키(public key)로, 한 쌍의 키를 사용한다.

개인 키 = 열쇠, 공개 키 = 자물쇠로 생각하면 된다. 자물쇠에는 누구나 접근이 가능하지만 이를 열 수 있는 것은 본인이 가진 열쇠로만 가능하다.

Use Case - SSH

Password를 사용하기에는 위험성이 따르기 때문에 키 페어를 사용하여 SSH 액세스를 보안하고자 한다. 키 페어를 생성하기 위해 ssh-keygen 명령을 실행한다. 해당 명령은 개인 키로 id_rsa를 생성하고, 공개 키로 id_rsa.pub를 생성한다. 그 다음 서버의 모든 접근을 차단하고, 공개 키를 통해서만 접근할 수 있도록 서버를 보호한다. 이는 일반적으로 서버의 ~/.ssh/authorized_keys 파일에 공개 키를 추가함으로써 이뤄진다. 이제 SSH에 누구나 공개 키에 접근할 수 있지만, 개인 키는 본인만 (노트북 등에) 보관하고 있기 때문에 누구도 서버에 접근할 수 없다.

SSH에 대한 동일한 개인 키를 여러 서버에 사용할 수 있기 때문에, 다른 서버가 있다면 공개 키 사본을 만들어 원하는 만큼 서버에 두어 접근을 막을 수 있다. 다른 사용자가 서버에 접근해야 되는 경우에는 해당 사용자의 키 페어 중 공용 키를 ~/.ssh/authorized_keys에 추가하면 접속이 가능하다.

With Symmetric Encryption

▶️ With Secure Connectivity 에서 데이터에 대한 암호화를 진행했지만 서버에게 키를 전달해야 했고, 이 과정에서 해커 또한 키를 가로챌 수 있기 때문에 복호화할 수 있다는 문제가 있었다. Symmetric과 Asymmetric Encryption을 함께 사용하여 이 문제를 해결할 수 있다.

서버에서 키 페어를 생성한다.

# 개인 키 생성: openssl genrsa -out [pri-keyname] [key-length]
openssl genrsa -out my-bank.key 1024

# 공개 키 생성: openssl rsa -in [pri-keyname] -pubout > [pub-keyname]
openssl rsa -in my-bank.key -pubout > mybank.pem
Bash
복사

•

key-length: 키의 비트 길이를 지정한다. RSA의 경우에는 최소 2048비트 이상을 권장한다.

HTTPS로 웹 서버 액세스

•

사용자가 HTTPS를 통해 웹 버서에 처음 액세스하면 서버에서 공개 키를 받게 된다.

•

해커도 네트워크를 스니핑하고 있어 공개 키를 받는다.

Symmetric Encryption

•

유저의 브라우저가 서버로부터 전달받은 공개 키를 통해 대칭 키(symmetric key)를 암호화한다.

암호화된 symmetric key 전송

•

암호화한 대칭 키를 서버로 전송한다.

•

이 과정에서 해커도 해당 복사본을 얻을 수 있다.

복호화

•

서버는 공개 키(자물쇠)에 대한 개인 키가 존재하여 유저가 암호화한 대칭 키를 얻을 수 있다.

•

하지만 해커는 개인 키가 없기 때문에 복호화는 진행하지 못한다.

•

이로써 대칭 키는 사용자와 서버만 사용할 수 있다.

데이터 전달

•

이제 사용자는 데이터를 암호화하여 서버로 보내면 서버에서는 대칭 키를 통해 데이터를 복호화할 수 있다.

•

해커는 데이터를 가로챌 수 있지만 복호화하지 못해 확인할 수 없다.

정리하면 다음과 같다.

•

사용자가 HTTPS로 접속하면 서버가 공개 키를 전달

•

사용자의 브라우저에서 전달받은 공개 키로 대칭 키 암호화

•

서버에서 개인 키를 통해 복호화하여 대칭 키 확보

•

사용자가 대칭 키를 사용해 암호화된 데이터를 전달하면 서버는 같은 대칭 키로 복호화

•

해커는 사용자와 서버로 간의 데이터들을 가로채지만 개인 키의 부재로 복호화하지 못함

Certificate

Senario

대칭 키와 비대칭 키를 함께 사용하여 해커가 암호화된 데이터에 접근할 수 없도록 만들었다. 하지만 해커가 데이터를 얻기 위해 다른 방법을 사용한다면 어떻게 해야할까? 해커가 사용자가 접속하려는 웹사이트를 똑같이 만들고, 네트워크를 조작해 자신의 서버로 보내는 경우를 생각해보자.

해커는 자신의 서버에 키 페어를 생성하고, 사용자를 자신의 서버에 접속하게 한다. 해커 서버는 공개 키를 사용자에게 보내고, 사용자는 해당 키를 통해 대칭 키를 해커 서버에 보낸다. 해커 서버는 이제 사용자의 대칭 키를 얻었고, 사용자가 로그인 데이터를 보내면 해당 자격 증명이 해커에게 넘어가게 된다.

Certificate

이를 해결하려면 어떻게 해야할까? 서버가 키를 혼자 보내는 것이 아니라 키를 가진 인증서를 보내는 것이다. 인증서는 인증서가 발급된 주체에 대한 정보, 해당 서버의 공개 키, 서버의 위치 등 다양한 정보를 포함한다. 모든 인증서에는 이름(name)이 있으며, 이는 인증서가 발급되는 사람이나 주체를 가리키기에 신원을 확인하는데 있어 매우 중요하다.

웹 서버에 대한 인증서라면 이름(name)은 사용자가 브라우저의 URL에 입력한 것과 일치해야 한다. 만약 은행이 다른 이름으로도 알려져 있고, 사용자가 다른 이름으로도 애플리케이션에 접근할 수 있게 하려면, 모든 이름을 인증서의 Subject 필드 아래 Alternative Name 섹션에 지정되어야 한다.

Sign

하지만 인증서는 누구나 생성이 가능하기 때문에 인증서가 진품인지 확인할 수 있어야 한다. 인증서에서 가장 중요한 부분이다. 인증서를 생성하면 직접 서명을 해야 하고, 이를 self-signed certificated 라고 한다.

모든 웹 브라우저는 인증서 유효성 검사(Certificate Validation) 메커니즘을 가지고 있으며, 브라우저 텍스트에서 서버로부터 인증서를 받아 인증서를 검증한다. 인증서가 유효하지 않으면 브라우저는 사용자에게 경고를 표시한다.

Certificate Authority (CA)

웹 브라우저가 신뢰할 웹서버 인증서는 어떻게 만들까? 권한 있는 사람이 인증서에 서명을 어떻게 할까?

이때 CA가 등장한다. CA는 우리를 대신해 우리의 인증서에 사인하고 검증을 해주는 기관이다. 대표적으로는 Symantec, DigiCert, Comodo, GlobalSign 등이 있다.

Sign Certificates

CSR: 이전에 생성한 키와 웹사이트의 도메인 이름을 사용하여 인증서 서명 요청(CSR, Certificate Signing Request)을 생성한다. OpenSSL 명령어를 사용하여 .csr 파일을 생성할 수 있다. CSR 파일은 CA에 서명을 요청하기 위해 전송되어야 한다. 

# openssl req -new -key [개인 키 파일] -out [생성할 CSR 파일] -subj "/CN=[도메인 이름]"
openssl req -new -key my-bank.key -out my-back.csr \
-subj "/C=US/ST=CA/O=MyOrg, Inc./CN=my-bank.com"
Bash
복사

Validate Infromation: CA에서는 제출된 정보의 진위를 확인한다. CA는 실제 도메인의 소유자가 맞는지 확인하기 위해 다양한 기법들을 사용한다.

Sign and Send Certificate: 확인이 완료되면 CA는 인증서에 서명을 하여 사용자에게 반환한다.

해커가 같은 방식으로 인증서에 서명을 받으려 하면 검증 단계를 통과하지 못해 CA에게 거부된다.

How Browsers Verify CA Legitimacy

CA 자체도 pub-pri 키 페어를 가지고 있다. CA는 인증서에 서명을 할 때 개인키를 사용한다. 모든 CA의 공개 키는 브라우저에 내장되어 있는데, 브라우저는 CA의 공개키를 통해 인증서가 실제로 CA에 의해 서명되었음을 검증한다.

브라우저에 내장된 CA는 공공 웹사이트(예: 은행, 이메일 등)의 신뢰성을 보장하지만, 조직 내부에서 호스팅되는 사이트의 검증에는 도움되지 않는다. 따라서 내부적으로 사용할 수 있는 개인 CA를 호스팅해야 한다. 대부분의 CA가 내부에 배포할 수 있는 CA 서버 서비스를 제공한다. 이로써 조직원들은 브라우저에 내부 CA 서버의 공개 키를 설치하여 조직 내에서 안전한 연결을 구축할 수 있다.

인증서를 어떻게 검증할까? | ghdwlsgur 기술블로그

브라우저들은 신뢰한 루트 인증서 리스트를 가지고 있다고 하는데 어디에 가지고 있는걸까 ?

https://ghdwlsgur.github.io/blog/2023/07/20

Summary

각 키페어에 대해 색으로 표현하고 어디에 위치해있는지 정리하며 표현해보았다

관리자는 한 쌍의 키로 서버의 SSH 연결 보안

•

서버 - Pub

•

관리자 - Pri

서버는 또 다른 키페어를 통해 HTTPS 트래픽 확보

•

서버 - Pub, Pri

이때 HTTPS 인증을 위해 서버는 CA에 인증서 서명 요청을 보냄 (CSR은 개인 키로 암호화)

•

서버 - Pub, Pri

•

CA - CSR(Pub), Pub, Pri

CA는 개인 키로 CSR에 서명하여 인증서를 서버로 전송
서명된 인증서로 웹 애플리케이션 배포

•

서버 - Pub, Pri, CERT(Pub)

사용자가 웹 서버에 액세스할 때마다 서버는 공개 키를 담은 인증서를 보냄

•

사용자 - Pub, CERT(Pub)

브라우저는 인증서를 읽고 서버의 공개키를 검증하고 얻기 위해 CA 공개키를 사용

•

사용자 - Symm Key, Pub, Pub

사용자는 서버의 공개키로 대칭키를 암호화하여 서버로 전송

•

서버 - Pub, Pri, CERT(Pub), Pub(Symm Key)

•

사용자 - Symm Key, Pub, Pub

서버는 개인키로 메시지를 해독하고 대칭키를 얻음
이 대칭키를 통해 사용자와 통신을 이어감

•

서버 - Pub, Pri, CERT(Pub), Symm Key

•

사용자 - Symm Key, Pub, Pub

Extra

TLS Client Certification

클라이언트는 서버의 유효성을 서버의 인증서를 통해 확인하는데, 반대로 서버는 클라이언트를 어떻게 확인할 수 있을까? 확인의 방법 중 하나로, 서버에서 클라이언트의 인증서를 요청할 수 있다. 클라이언트가 CA로부터 서명된 인증서를 생성하여 서버에게 인증서를 보내 클라이언트에 대한 검증이 이뤄지게 할 수 있다.

웹 서버에서는 TLS 클라이언트 인증서가 일반적으로 구현되지 않아 수동으로 생성 및 관리할 필요가 없다. 하지만 호스트 내에서는 모두 구현되어 있다.

PKI

CA, 서버, 디지털 인증서를 생성하고 배포하는 프로세스를 포함한 모든 인프라를 Public Key Infrastructure라고 한다.

Key Pair

데이터를 암호화할 수 있는 것은 키 페어뿐만이 아니다.

개인 키로 암호화한 데이터는 공개 키를 가진 누구나 데이터를 복호화할 수 있다.

반대로 공개 키로 암호화한 데이터는 개인 키를 가진 사람만 데이터를 복호화할 수 있다.

Naming Convention

개인 키는 이름이든 확장자든 key라는 단어를 포함하며, 일반 공용키나 인증서는 그렇지 않다.

Certificate (Public Key) .crt .pem	Private Key .key -key.pem
server.crt server.pem client.crt client.pem	server.key server-key.pem client.key client-key.pem