HTTPS / TLS / 암호화 면접 질문

HTTP와 HTTPS의 가장 큰 차이점은 보안입니다. HTTP는 데이터를 암호화하지 않고 평문으로 전송하는 반면, HTTPS는 TLS/SSL 프로토콜을 사용하여 데이터를 암호화합니다.

HTTPS가 제공하는 주요 보안 이점은 다음과 같습니다. 첫째, 기밀성입니다. 암호화를 통해 중간에서 데이터를 가로채더라도 내용을 해독할 수 없습니다. 둘째, 무결성입니다. 데이터 전송 중에 변조가 발생하면 이를 감지할 수 있습니다. 셋째, 인증입니다. 서버 인증서를 통해 사용자가 접속하는 서버가 진짜인지 확인할 수 있습니다. 즉, 피싱 공격을 방지할 수 있습니다.

TLS(Transport Layer Security)는 웹 통신에서 클라이언트와 서버 간의 안전한 통신을 제공하는 암호화 프로토콜입니다. HTTPS는 HTTP 프로토콜 위에 TLS를 얹어 보안을 강화한 것입니다.

TLS의 핵심 역할은 크게 세 가지입니다. 첫째, 암호화를 통해 데이터를 보호하여 제3자가 내용을 엿볼 수 없도록 합니다. 둘째, 인증을 통해 서버의 신원을 확인하여 위조된 서버에 접속하는 것을 방지합니다. 셋째, 데이터 무결성을 보장하여 전송 중에 데이터가 변조되지 않았음을 확인합니다.

TLS 핸드셰이크 과정을 통해 암호화에 필요한 키를 안전하게 교환하고, 이후 모든 통신은 암호화된 상태로 이루어집니다. 이를 통해 개인 정보, 금융 정보 등 민감한 데이터를 안전하게 주고받을 수 있습니다.

네, 대칭키 암호화와 비대칭키 암호화에 대해 설명드리겠습니다.

대칭키 암호화는 암호화할 때 사용하는 키와 복호화할 때 사용하는 키가 동일한 방식입니다. 가장 큰 장점은 암복호화 속도가 매우 빠르다는 점입니다. 하지만 단점으로는 암호화된 데이터를 주고받는 두 당사자 간에 미리 동일한 키를 안전하게 공유해야 한다는 점이 있습니다. AES 같은 알고리즘이 대표적입니다.

반면에 비대칭키 암호화는 암호화할 때 사용하는 공개키와 복호화할 때 사용하는 개인키가 서로 다른 방식입니다. 공개키는 누구나 알 수 있지만, 개인키는 소유자만 가지고 있어야 합니다. 이 방식의 가장 큰 장점은 안전한 키 교환이 가능하다는 것입니다. 상대방의 공개키로 암호화하면 오직 그 사람의 개인키로만 복호화할 수 있기 때문입니다. 단점으로는 대칭키 방식보다 암복호화 속도가 느리다는 점이 있습니다. RSA 알고리즘이 대표적입니다.

HTTPS/TLS에서는 이 두 가지 방식을 함께 사용합니다. 처음 통신을 시작할 때는 비대칭키 암호화를 이용해 안전하게 대칭키를 교환하고, 이후 실제 데이터 통신은 빠른 대칭키 암호화를 사용합니다.

TLS 핸드셰이크의 주된 목적은 클라이언트와 서버 간에 안전한 통신 채널을 구축하는 것입니다. 이를 위해 세 가지 중요한 목표를 달성합니다.

첫째, 클라이언트와 서버는 서로 지원하는 암호화 알고리즘 목록을 교환하고, 가장 안전하고 효율적인 알고리즘 조합을 선택합니다.

둘째, 서버는 자신의 인증서를 클라이언트에게 제공하여 신원을 증명합니다. 클라이언트는 이 인증서를 검증하여 서버가 진짜인지 확인합니다.

셋째, 클라이언트와 서버는 이후 통신을 암호화하는 데 사용할 세션 키를 안전하게 교환합니다. 이 세션 키는 핸드셰이크 과정에서만 사용되며, 이후 데이터 전송에는 사용되지 않아 보안성을 높입니다.

결론적으로, TLS 핸드셰이크는 암호화, 인증, 키 교환을 통해 안전한 통신을 위한 기반을 마련하는 핵심적인 과정입니다.

HTTPS 통신에서 서버 인증서는 서버의 신원을 보장해주는 역할을 합니다. 쉽게 말해, 클라이언트가 접속하려는 서버가 진짜 그 서버인지 확인시켜주는 일종의 '신분증' 같은 거죠.

인증서가 필요한 이유는 중간자 공격을 막기 위해서입니다. 인증서가 없으면 공격자가 서버인 척 위장해서 클라이언트의 정보를 가로챌 수 있습니다.

인증서 안에는 서버의 공개키가 들어있는데, 클라이언트는 이 공개키를 이용해서 서버와 안전하게 암호화 통신을 할 수 있습니다. 서버는 자신의 개인키를 이용해서 데이터를 암호화하고, 클라이언트는 서버의 공개키로 암호화된 데이터를 복호화하는 방식입니다. 인증서를 통해 안전하게 공개키를 전달하고, 서버의 신뢰성을 확보하는 것이 HTTPS의 핵심입니다.

CA는 Certificate Authority, 즉 인증 기관을 의미합니다. 인터넷 환경에서 웹사이트의 신뢰성을 보장하는 역할을 하죠.

CA는 디지털 인증서를 발급하고 관리하는데, 웹사이트의 공개키를 인증서에 담아 CA의 전자 서명으로 보증합니다. 사용자가 웹사이트에 접속할 때, 브라우저는 해당 웹사이트의 인증서를 확인하고, 인증서가 신뢰할 수 있는 CA에 의해 발급되었는지 검증합니다.

이 과정은 신뢰 체인으로 이루어집니다. 브라우저는 미리 CA 목록(루트 인증 기관)을 가지고 있고, 웹사이트 인증서가 이 루트 CA로부터 발급되었거나, 루트 CA가 신뢰하는 다른 CA로부터 발급되었는지 확인하는 방식으로 신뢰성을 검증합니다. 만약 인증서가 유효하지 않거나 신뢰할 수 없는 CA에서 발급되었다면, 브라우저는 사용자에게 경고 메시지를 표시합니다.

공개키와 개인키는 비대칭 키 암호화 방식의 핵심입니다. 공개키는 이름 그대로 누구나 접근할 수 있으며, 데이터를 암호화하거나 디지털 서명을 검증하는 데 사용됩니다. 반면 개인키는 오직 소유자만이 안전하게 보관해야 하며, 공개키로 암호화된 데이터를 복호화하거나 디지털 서명을 생성하는 데 사용됩니다.

HTTPS 통신에서는 이 두 키가 TLS/SSL 핸드셰이크 과정에서 중요한 역할을 합니다. 클라이언트(브라우저)가 서버에 접속하면, 서버는 자신의 공개키가 포함된 인증서를 클라이언트에게 전달합니다. 클라이언트는 이 공개키를 이용해 통신에 사용할 대칭키를 암호화하여 서버로 보냅니다. 서버는 자신의 개인키로 이 대칭키를 복호화하여 얻고, 이후부터는 이 대칭키를 이용해 빠르고 효율적으로 데이터를 암호화하여 통신합니다. 이를 통해 통신의 기밀성과 서버의 신뢰성을 보장합니다.

HTTPS 통신 시 TLS 핸드셰이크는 클라이언트와 서버가 안전하게 통신하기 위한 초기 과정입니다.

먼저, 클라이언트가 ClientHello 메시지를 보내 지원하는 TLS 버전, 암호화 스위트 등을 알립니다. 서버는 ServerHello 메시지로 사용할 TLS 버전과 암호화 스위트를 선택하고, 자신의 인증서를 클라이언트에게 보냅니다.

클라이언트는 서버 인증서의 유효성을 검증하고, 이 인증서에 포함된 서버의 공개키를 사용하여 통신에 사용할 대칭키를 생성합니다. 이 대칭키를 서버의 공개키로 암호화하여 서버에게 전송합니다.

서버는 자신의 개인키로 암호화된 대칭키를 복호화하고, 클라이언트와 동일한 대칭키를 생성합니다. 마지막으로, 클라이언트와 서버는 각각 Finished 메시지를 보내 핸드셰이크가 성공적으로 완료되었음을 확인합니다. 이후 모든 통신은 이 대칭키를 사용하여 암호화됩니다.

이 과정에서 비대칭키는 인증서 검증과 대칭키 교환에 사용되어 보안을 강화하고, 대칭키는 실제 데이터 암호화에 사용되어 빠른 통신을 가능하게 합니다.

웹 브라우저가 서버의 SSL/TLS 인증서를 신뢰하는 과정에서 CA(인증기관)는 서버의 신원을 보증하는 역할을 합니다. CA는 신뢰할 수 있는 제3자로서, 서버의 공개 키를 인증하고 디지털 서명을 통해 위조를 방지합니다.

신뢰 체인은 루트 CA 인증서부터 시작하여 중간 CA 인증서를 거쳐 최종적으로 서버 인증서까지 연결되는 계층 구조입니다. 브라우저는 미리 설치된 루트 CA 인증서를 가지고 있고, 이 루트 CA가 서명한 중간 CA 인증서를 신뢰합니다. 중간 CA는 서버 인증서를 서명하고, 브라우저는 이 과정을 통해 서버 인증서의 유효성을 검증합니다. 즉, 루트 CA -> 중간 CA -> 서버 인증서 순으로 신뢰가 전파되는 것입니다. 만약 체인 중 하나라도 유효하지 않으면 브라우저는 해당 서버를 신뢰하지 않습니다.

HTTPS에서 Perfect Forward Secrecy (PFS)는 특정 세션의 암호화 키가 유출되더라도 과거 세션의 암호화된 데이터를 해독할 수 없도록 하는 보안 속성입니다. 즉, 세션 키가 서버의 장기 개인 키에 종속되지 않도록 하는 것이 핵심입니다.

PFS를 제공하기 위해 주로 Diffie-Hellman (DH) 계열의 키 교환 알고리즘이 사용됩니다. 예를 들어, Ephemeral Diffie-Hellman (DHE)이나 Elliptic-Curve Diffie-Hellman Ephemeral (ECDHE) 등이 있습니다. 이 알고리즘들은 매 세션마다 새로운 임시 키를 생성하여 세션 키를 만들기 때문에, 하나의 키가 유출되더라도 다른 세션에는 영향을 미치지 않습니다.

PFS는 과거 데이터의 보안을 유지하는 데 매우 중요합니다. 만약 서버의 개인 키가 탈취당하더라도, PFS가 적용된 과거 세션의 데이터는 안전하게 보호될 수 있습니다. 따라서, 현대 웹 보안에서 필수적인 요소로 여겨집니다.

TLS 핸드셰이크에서 클라이언트와 서버는 'Cipher Suite'를 협상하여 통신 보안을 설정합니다.

먼저 클라이언트는 ClientHello 메시지를 보내 자신이 지원하는 Cipher Suite 목록을 서버에 알립니다. 이 목록에는 키 교환 알고리즘, 인증 방식, 대칭 암호화 알고리즘, 해싱(MAC) 알고리즘 등이 포함됩니다.

서버는 받은 목록을 검토하고, 자신이 지원하는 것 중 가장 안전하고 효율적인 Cipher Suite를 선택하여 ServerHello 메시지로 클라이언트에게 응답합니다. 이렇게 선택된 Cipher Suite는 이후 통신에서 사용할 암호화 및 인증 방식을 결정하게 됩니다.

Cipher Suite는 보통 다음과 같은 요소들로 구성됩니다.

• 키 교환 알고리즘 (Key Exchange Algorithm): 세션 키를 안전하게 교환하는 방식입니다. 예를 들어, ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) 등이 있습니다.
• 인증 방식 (Authentication): 서버의 신원을 확인하는 방식입니다. 주로 RSA 또는 ECDSA와 같은 디지털 서명 알고리즘을 사용합니다.
• 대칭키 암호화 알고리즘 (Bulk Encryption Algorithm): 실제 데이터를 암호화하는 데 사용되는 알고리즘입니다. AES (Advanced Encryption Standard)가 대표적입니다.
• 해싱 알고리즘 (Hashing Algorithm / MAC): 데이터 무결성을 보장하고 메시지 인증 코드(MAC)를 생성하는 데 사용됩니다. SHA-256 등이 있습니다.

HSTS는 HTTP Strict Transport Security의 약자로, 웹사이트가 브라우저에게 항상 HTTPS를 사용하도록 강제하는 보안 메커니즘입니다. 웹 애플리케이션 보안에 기여하는 방식은 다음과 같습니다.

첫째, 중간자 공격(Man-in-the-Middle attack)을 방지합니다. 사용자가 실수로 HTTP 링크를 클릭하거나 HTTP로 접속해도, HSTS 헤더가 설정된 서버는 브라우저에게 자동으로 HTTPS로 연결하도록 지시합니다. 이는 공격자가 HTTP 통신을 가로채 민감한 정보를 탈취하는 SSL 스트리핑 공격을 효과적으로 막아줍니다.

둘째, 보안을 강화합니다. 사용자가 직접 HTTPS 주소를 입력하지 않아도 항상 암호화된 통신을 보장받게 되어, 데이터 전송의 기밀성과 무결성을 높입니다.

HSTS 적용의 장점은 앞서 말한 보안 강화와 중간자 공격 방지입니다. 또한, 브라우저가 서버에 처음 접속할 때 HTTPS로 연결을 시도하므로, 초기 연결에서의 보안 취약점을 줄일 수 있습니다.

고려사항으로는, HSTS를 적용하면 HTTP로의 접속이 완전히 차단되므로, SSL/TLS 인증서에 문제가 있거나 HTTPS 설정이 잘못된 경우 사용자가 웹사이트에 접속하지 못하는 상황이 발생할 수 있습니다. 따라서 HSTS 적용 전에 HTTPS 설정이 완벽한지 충분히 테스트해야 합니다. 또한, HSTS 정책은 브라우저에 캐시되므로, 잘못 설정했을 경우 이를 해제하는 데 시간이 걸릴 수 있습니다. 'preload' 목록에 등록하면 브라우저가 처음부터 HSTS를 인지하게 되어 보안을 더욱 강화할 수 있지만, 한번 등록하면 되돌리기 어렵기 때문에 신중한 결정이 필요합니다.

TLS 1.2와 1.3의 가장 큰 차이점은 핸드셰이크 과정과 암호화 방식입니다. TLS 1.3은 핸드셰이크를 1-RTT로 줄여 연결 시간을 단축했습니다. 이전 버전에서는 2-RTT가 필요했죠.

보안 측면에서는 취약한 암호화 알고리즘을 제거하고, AEAD(Authenticated Encryption with Associated Data) 암호화 방식을 기본으로 사용해 보안성을 높였습니다. 또한 Perfect Forward Secrecy(PFS)를 강제화하여 과거의 키가 노출되더라도 과거 통신 내용을 복호화할 수 없도록 했습니다.

이러한 변화로 TLS 1.3은 TLS 1.2보다 더 빠르고 안전한 통신을 제공합니다.

SNI는 HTTPS에서 하나의 IP 주소에 여러 웹사이트를 호스팅할 때 발생하는 문제를 해결하기 위해 도입되었습니다. 이전에는 서버가 어떤 도메인으로 접속하는지 알 수 없어, 모든 도메인에 대해 동일한 SSL/TLS 인증서를 사용해야 했습니다. 이로 인해 보안 및 관리상의 문제가 발생했습니다.

SNI는 TLS 핸드셰이크 과정에서 클라이언트가 접속하려는 서버 이름을 명시적으로 알려주는 확장 기능입니다. 클라이언트는 TLS 연결을 시작할 때 ClientHello 메시지에 접속하려는 도메인 이름을 포함하여 전송합니다. 서버는 이 정보를 바탕으로 해당 도메인에 맞는 올바른 SSL/TLS 인증서를 선택하여 클라이언트에게 제공합니다. 이를 통해 각 도메인별로 고유한 인증서를 사용할 수 있게 되어 보안이 강화되고 가상 호스팅 환경에서의 HTTPS 적용이 가능해졌습니다.

TLS 1.3의 0-RTT 모드는 클라이언트가 이전 세션 정보를 활용해 첫 번째 요청부터 데이터를 바로 보내므로 연결 설정 시간을 단축합니다. 하지만 이 과정에서 가장 큰 보안 위험은 '재생 공격(Replay Attack)'입니다. 공격자가 이전 세션에서 가로챈 Early Data 패킷을 그대로 다시 보내 서버가 이를 유효한 요청으로 처리하게 만들 수 있습니다.

이 위험을 완화하기 위해 서버는 몇 가지 기술적 접근 방식을 사용합니다. 첫째, 서버는 0-RTT로 받은 요청이 '멱등성(Idempotent)'을 가지는지 확인합니다. 즉, 동일한 요청을 여러 번 수행해도 결과가 동일해야 합니다. 예를 들어, 상품 구매와 같은 멱등성이 없는 요청은 0-RTT로 허용하지 않을 수 있습니다. 둘째, 서버는 '재생 방지(Anti-Replay)' 메커니즘을 구현합니다. 이는 각 0-RTT 데이터에 고유한 식별자나 타임스탬프를 부여하고, 서버는 이전에 받은 식별자나 타임스탬프를 기록하여 중복된 요청을 거부하는 방식입니다. AEAD(Authenticated Encryption with Associated Data) 암호화 방식도 재생 공격 방지에 기여합니다.

Perfect Forward Secrecy, 즉 PFS는 HTTPS 통신에서 매우 중요한 보안 이점을 제공합니다. 핵심은 서버의 장기 개인 키가 유출되더라도, 과거에 이루어졌던 모든 통신 세션의 암호화 키가 노출되지 않는다는 것입니다.

이를 구현하기 위해 TLS 핸드셰이크 과정에서는 임시 키 교환(Ephemeral Key Exchange) 방식을 사용하는 키 교환 알고리즘이 필수적입니다. 가장 대표적인 예로는 **ECDHE(Elliptic Curve Diffie-Hellman Ephemeral)**가 있습니다.

ECDHE는 각 세션마다 새로운 임시 키 쌍을 생성하여 키를 교환합니다. 이 임시 키는 세션이 종료되면 폐기되므로, 설령 서버의 장기 개인 키가 나중에 유출되더라도 이전에 사용했던 세션 키를 복구하는 데 사용할 수 없습니다. 즉, 과거 통신 기록의 기밀성을 강력하게 보장하는 것입니다.

HPKP는 클라이언트가 특정 서버의 인증서 또는 공개키를 미리 저장해두고 연결 시 이를 검증하는 방식입니다. 보안은 강화되지만, 설정 오류나 키 변경 실패 시 서비스 장애를 유발할 위험이 컸습니다. 키를 잃어버리거나 잘못된 키를 고정했을 경우 복구가 매우 어려웠죠.

반면 Certificate Transparency (CT)는 인증서 발급 내역을 공개적으로 로깅하여 감시하는 방식입니다. CA가 잘못된 인증서를 발급하더라도 빠르게 탐지할 수 있고, 도메인 소유자는 자신의 도메인에 대한 인증서 발급 내역을 쉽게 확인할 수 있습니다. HPKP처럼 서비스 중단 위험 없이 인증서 생태계 전반의 신뢰도를 높이는 데 기여합니다. CT는 자동화된 모니터링과 유연한 대응이 가능하다는 장점도 있습니다.

MSA 환경에서 서비스 간 인증 강화를 위해 mTLS를 도입하는 것은 좋은 선택입니다. mTLS는 기존 단방향 TLS와 달리, 클라이언트와 서버 모두 인증서를 제시하여 서로를 인증하는 방식입니다. 이를 통해 서비스 위조를 방지하고, 보안을 더욱 강화할 수 있습니다.

기존 TLS 대비 mTLS의 가장 큰 이점은 상호 인증을 통해 신뢰할 수 있는 서비스만 통신하도록 보장한다는 점입니다.

실제 MSA 환경에서 mTLS를 구축할 때 몇 가지 고려해야 할 기술적 과제가 있습니다. 첫째, 인증서 관리입니다. 서비스가 많아질수록 인증서 발급, 배포, 갱신, 폐기 관리가 복잡해집니다. 이를 해결하기 위해 자동화된 인증서 관리 시스템(예: HashiCorp Vault)을 구축하고, 인증서 갱신 주기를 자동화하는 것이 중요합니다.

둘째, 성능 오버헤드입니다. mTLS는 암호화 연산이 추가되므로 서비스 성능에 영향을 줄 수 있습니다. Sidecar Proxy(예: Istio)를 사용하여 mTLS를 구현하면 서비스 코드 변경 없이 트래픽 암호화 및 인증을 처리할 수 있지만, Proxy 자체의 성능도 고려해야 합니다. 성능 테스트를 통해 적절한 설정 값을 찾아야 합니다.

마지막으로, 인증서 폐기 문제입니다. 서비스에 문제가 발생했을 때 해당 서비스의 인증서를 즉시 폐기하고, 폐기된 인증서를 사용하는 서비스의 접근을 차단해야 합니다. CRL(Certificate Revocation List) 또는 OCSP(Online Certificate Status Protocol)를 사용하여 인증서 폐기 상태를 관리할 수 있습니다.

TLS 구현체는 Side-Channel Attack에 취약할 수 있습니다. 예를 들어, Lucky 13 공격은 CBC 모드 암호화에서 패딩 오류 처리 시간 차이를 이용해 암호문을 해독합니다. BEAST 공격은 TLS 1.0의 CBC 모드에서 IV 예측 가능성을 악용하고, CRIME 공격은 HTTP 압축을 이용해 쿠키를 탈취합니다.

이러한 공격을 방어하기 위해 현대적인 TLS 프로토콜은 다음과 같은 원칙을 따릅니다. 첫째, AEAD(Authenticated Encryption with Associated Data) 모드를 사용합니다. AEAD는 암호화와 인증을 동시에 수행하여 무결성을 보장하고, 패딩 오라클 공격을 방지합니다. 둘째, TLS 1.3은 안전하지 않은 암호화 방식과 기능을 제거하고, Key Exchange 방식을 개선하여 보안성을 강화했습니다. 셋째, Side-Channel Resistant 구현을 통해 연산 시간을 일정하게 유지하거나, 전력 소모 패턴을 숨기는 등의 기법을 적용합니다.

면접관님, 클라우드 환경에서 TLS Termination, Passthrough, Re-encryption은 각각 장단점이 뚜렷합니다.

TLS Termination은 로드 밸런서나 API 게이트웨이에서 암호화를 해제하여 서버의 부담을 줄이고, 부하 분산 및 트래픽 관리 효율성을 높입니다. 하지만 내부망 보안이 취약해질 수 있습니다.

TLS Passthrough는 암호화된 트래픽을 그대로 백엔드 서버로 전달하여 내부 보안은 유지되지만, 로드 밸런서가 트래픽 내용을 분석할 수 없어 고급 기능 활용이 어렵습니다.

TLS Re-encryption은 로드 밸런서에서 암호화를 해제한 후 다시 암호화하여 백엔드 서버로 전달합니다. End-to-End 암호화를 구현하여 보안을 강화하지만, 암호화/복호화 과정에서 성능 오버헤드가 발생할 수 있습니다.

보안과 성능은 트레이드오프 관계에 있으며, 서비스의 요구사항과 환경에 따라 적절한 방식을 선택해야 합니다. 예를 들어, 민감한 데이터를 다루는 서비스라면 Re-encryption을 고려하고, 성능이 중요한 서비스라면 Termination을 선택하는 것이 좋습니다.

PQC가 TLS에 통합되면 가장 큰 변화는 키 교환 알고리즘입니다. RSA나 ECC 대신, 격자 기반, 코드 기반, 다변수 기반 암호 등 양자 내성 알고리즘이 사용되겠죠.

성능 면에서는 초기에는 오버헤드가 불가피할 겁니다. PQC 알고리즘은 키 크기가 크고 연산량도 많아서, 핸드셰이크 시간이 늘어날 수 있습니다. 그래서 하이브리드 방식으로, 기존 암호와 PQC를 함께 사용하는 방식이 먼저 도입될 가능성이 높습니다.

호환성도 중요한 문제입니다. 기존 시스템과의 호환성을 유지하기 위해 점진적인 전환이 필요하고, 클라이언트와 서버 모두 PQC 알고리즘을 지원해야 합니다. 인증서 역시 PQC 알고리즘을 지원하도록 업데이트되어야 합니다.

배포 전략은 결국 성능과 호환성을 고려해서 결정될 텐데요. 하이브리드 모드를 통해 점진적으로 PQC 알고리즘의 비중을 늘려가는 방식이 현실적이라고 생각합니다.