HTTPS, SSL/TLS

HTTP vs HTTPS

HTTP(HyperText Transfer Protocol)와 HTTPS(HyperText Transfer Protocol Secure)는 인터넷을 통해 데이터를 전송하기 위한 프로토콜입니다. 주요한 차이점은 보안과 암호화입니다.

 

1. 보안:
   • HTTP: HTTP는 평문 텍스트로 데이터를 전송하기 때문에 보안이 제공되지 않습니다. 데이터가 암호화되지 않기 때문에 도청이나 데이터 변조와 같은 공격에 취약합니다.
   • HTTPS: HTTPS는 SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security) 프로토콜을 사용하여 데이터를 암호화합니다. 이를 통해 데이터의 기밀성과 무결성을 보호하고, 도청과 데이터 변조를 방지할 수 있습니다.
2. 암호화:
   • HTTP: HTTP는 암호화되지 않은 텍스트로 데이터를 전송합니다.
   • HTTPS: HTTPS는 공개 키 암호화 방식인 SSL/TLS 프로토콜을 사용하여 데이터를 암호화합니다. 이는 데이터의 안전한 전송을 보장하고 중간에서 데이터를 엿볼 수 없도록 합니다.
3. 포트 번호:
   • HTTP: HTTP는 기본적으로 80번 포트를 사용합니다.
   • HTTPS: HTTPS는 기본적으로 443번 포트를 사용합니다.

 

HTTPS는 주로 보안이 필요한 웹 페이지, 로그인 페이지, 결제 페이지 등에서 사용됩니다. 암호화된 연결을 통해 사용자의 개인 정보와 중요한 데이터를 보호하고 인증서를 통해 서버의 신뢰성을 확인할 수 있습니다. 따라서, 인터넷 상에서 보안이 중요한 정보를 주고받을 때는 HTTPS를 사용하는 것이 권장됩니다.

---

SSL/TLS

SSL(Secure Sockets Layer)과 TLS(Transport Layer Security)은 모두 암호화와 보안을 위한 프로토콜로, 주로 HTTPS를 통해 사용됩니다. 주요한 차이점은 다음과 같습니다.

1. 발전 경로:
   • SSL: SSL은 넷스케이프에서 개발되었으며, SSL 3.0이 가장 널리 사용되었습니다.
   • TLS: TLS는 SSL의 후속 버전으로서, IETF(Internet Engineering Task Force)에서 개발되었습니다. TLS 1.0부터 시작하여 현재는 TLS 1.3이 최신 버전입니다.
2. 보안 강화:
   • SSL: SSL은 초기 버전에서 취약점이 발견되고 해결되지 않았기 때문에, 보안 측면에서 취약합니다.
   • TLS: TLS는 SSL의 보안 취약점을 개선하고, 다양한 암호화 알고리즘과 보안 기능을 추가하여 보안성을 강화했습니다.

 

결국은 SSL 인증서는 클라이언트와 서버간의 통신을 제3자가 보증해주는 전자화된 문서입니다. SSL의 특징은 아래와 같습니다.

• 통신 내용이 공격자에게 노출되는 것을 막을 수 있다.
• 클라이언트가 접속하려는 서버가 신뢰 할 수 있는 서버인지를 판단 할 수 있다.
• 통신 내용의 악의적인 변경을 방지할 수 있다.

---

암호화/복호화

암호화와 복호화는 정보를 보호하고 안전하게 전송하기 위해 사용되는 암호학적인 개념입니다.

 

1. 암호화 (Encryption): 암호화는 원본 데이터를 암호 알고리즘을 사용하여 일련의 과정을 거쳐 암호문(암호화된 데이터)으로 변환하는 과정입니다. 암호화를 통해 데이터는 의미가 없는 형태로 변환되어 외부에서 알아볼 수 없도록 보호됩니다. 암호화에는 공개키 암호화와 대칭키 암호화 두 가지 주요한 방식이 있습니다.
   • 공개키 암호화: 공개키 암호화는 두 개의 서로 다른 키(공개키와 개인키)를 사용합니다. 데이터를 암호화할 때는 공개키를 이용하고, 이 암호문은 개인키로만 복호화할 수 있습니다. 공개키는 다른 사람과 공유되며, 개인키는 자신만이 소유하고 보호합니다. 대표적으로 RSA, ECC 알고리즘이 있습니다.
   • 대칭키 암호화: 대칭키 암호화는 동일한 키를 암호화와 복호화에 모두 사용합니다. 암호화할 때 사용한 키와 동일한 키를 가지고 있어야만 복호화가 가능합니다. 대칭키 암호화는 암호화와 복호화 속도가 빠르지만, 키 관리에 대한 문제가 있을 수 있습니다. 대표적으로 AES, DES, 3DES 등이 있습니다.
2. 복호화 (Decryption): 복호화는 암호화된 데이터(암호문)를 원래의 평문 데이터로 되돌리는 과정입니다. 복호화는 암호화된 데이터와 암호화에 사용된 알고리즘에 따라 올바른 키를 사용하여 수행됩니다. 정확한 키를 가지고 있어야만 암호문을 해독하여 원본 데이터를 복구할 수 있습니다. 암호화된 데이터를 복호화하지 않으면 의미있는 정보로서 활용할 수 없습니다.

 

암호화와 복호화는 보안과 개인 정보 보호를 위해 널리 사용되며, 데이터의 기밀성과 무결성을 보장하기 위한 중요한 기술입니다.

 

일반적인 암호화는 어떤 알고리즘을 사용했냐를 알고만 있어도 쉽게 복호화를 할 수 있게 됩니다. 이러한 문제점을 해결하기 위한 사용되는 방식으로 사용되는 것이 바로 공개키와 대칭키 방식입니다. 지정된 사람에게만 읽고 쓰게 할 수 있도록 하는 것이 매우 중요한 포인트입니다.

---

대칭키, 공개키

대칭키(일대일 키, Symmetric Key)는 암호화와 복호화에 동일한 키를 사용하는 암호화 방식입니다. 즉, 데이터를 암호화할 때 사용한 키와 동일한 키를 사용하여 복호화를 수행합니다. 대칭키 암호화는 암호화와 복호화 속도가 빠르고 간단한 구현이 가능한 장점이 있습니다.

 

대칭키 암호화는 데이터를 암호화할 때 사용하는 키와 동일한 키를 수신측이 가지고 있어야만 복호화가 가능합니다. 즉, 통신을 하는 모든 사용자가 동일한 키를 공유하고 있어야 합니다. 이는 키 관리의 어려움을 초래할 수 있으며, 대칭키를 안전하게 공유하는 문제가 발생할 수 있습니다.

대칭키 암호화는 대량의 데이터를 빠르게 암호화하고 복호화할 수 있는 장점이 있으며, 대칭키의 안전한 공유와 관리가 보장된다면 효과적으로 보안을 제공할 수 있습니다.

 

공개키(비대칭키, Public Key)는 암호화와 복호화에 각각 다른 키를 사용하는 암호화 방식입니다. 데이터를 암호화할 때는 공개키를 사용하고, 이 암호문은 개인키로만 복호화할 수 있습니다. 즉, 공개키는 다른 사람과 공유되고, 개인키는 해당 키를 소유하고 있는 개인만이 가지고 있어야 합니다.

공개키 암호화는 공개키와 개인키라는 한 쌍의 키를 사용합니다. 공개키는 다른 사람들과 공유될 수 있으며, 이를 이용하여 암호화된 데이터를 생성할 수 있습니다. 이 암호문은 개인키로만 복호화할 수 있습니다. 따라서, 암호화된 데이터를 보내는 사람은 수신자의 공개키를 사용하여 데이터를 암호화하고, 수신자는 자신의 개인키를 사용하여 암호문을 복호화하여 원본 데이터를 얻을 수 있습니다.

 

공개키 암호화는 키 관리와 보안의 어려움을 대칭키 암호화에 비해 해결할 수 있습니다. 수신자의 공개키는 공개되어 있어도, 암호문을 복호화하기 위해서는 해당 키를 가지고 있는 개인만이 가지고 있어야 하기 때문입니다. 이는 데이터의 기밀성과 무결성을 보호하고, 안전한 통신을 제공합니다.

 

공개키 암호화는 대칭키 암호화에 비해 보안성과 키 관리의 편의성을 제공하지만, 암호화 및 복호화 과정이 대칭키 암호화보다 느리다는 단점이 있습니다. 그러므로 공개키와 대칭키를 혼합하여 사용하는 하이브리드 암호화 방식이 널리 활용됩니다.

---

CA(Certificate authority), Root Certificate

CA(Certificate Authority, 인증기관)는 디지털 인증서를 발급하고 관리하는 신뢰할 수 있는 기관입니다. CA는 공개키 인프라(Public Key Infrastructure, PKI)의 일부로서 인증서의 유효성을 보증하고, 공개키를 사용하여 암호화와 인증을 수행합니다.

 

CA는 인증서를 발급하는데 필요한 신원 검증 절차를 수행하고, 인증서에 서명하여 신뢰할 수 있는 인증서 체인을 형성합니다. CA는 보통 상업적인 목적을 가지며, 예를 들어 인터넷 브라우저에서 신뢰할 수 있는 인증서를 제공하는 기관입니다.

Root Certificate(루트 인증서)는 CA의 최상위 인증서로서, 모든 인증 체인의 시작점입니다. 루트 인증서는 자체 서명되어 있으며, 브라우저와 운영체제에 미리 설치되어 있어 신뢰할 수 있는 기관으로서의 역할을 합니다. 따라서, Root Certificate는 신뢰할 수 있는 CA의 인증서를 발급하고 있는지 확인하는데 사용됩니다.

 

일반적으로 브라우저나 운영체제는 미리 신뢰할 수 있는 CA의 루트 인증서 목록을 내장하고 있습니다. 이 루트 인증서들은 신뢰할 수 있는 CA들로부터 서명된 인증서를 식별하고, 해당 인증서의 유효성을 검증하는데 사용됩니다. 따라서, CA의 루트 인증서를 신뢰할 수 있다면 해당 CA로부터 발급된 인증서를 신뢰할 수 있게 됩니다.

루트 인증서는 하위 수준의 CA 인증서를 발급하는데 사용되고, 이러한 하위 CA들은 다시 자신의 서브 CA들에게 인증서를 발급할 수 있습니다. 이런 식으로 인증 체인이 형성되며, 루트 인증서에서부터 최종 사용자에게 도달하는 모든 인증서는 서명된 상위 CA의 신뢰성에 의존합니다.

---

인증 과정

네트워크 연결 방식으로 사용되는 3-way-handshake를 통해 인증서와 데이터를 주고 받으면서 서버와의 통신을 받을 준비를 합니다. 이러한 과정에서 어떠한 데이터를 주고 받고 있는지 알아보도록 하겠습니다.

1. 클라이언트는 서버에 접근시 클라이언트가 생성한 랜덤 데이터, 지원가능한 암호화 방식, 세션 아이디를 서버에 넘겨줍니다.
2. 서버에서는 클라이언트가 넘겨준 지원가능한 암호화 방식 중 하나를 선택, 다시 클라이언트에게 서버가 생성한 랜덤 데이터, 암호화 방식, 인증서(CA, 공개키)를 넘겨줍니다.
3. 클라이언트는 서버에서 받은 인증서를 받고 먼저 서버의 공개키에 연동되는 개인키를 생성합니다.
4. CA인증서 내에 있는 공개키를 검증하기 위하여 Root인증기관 List에 해당 서버가 존재하는지 확인 합니다.
5. 클라이언트는 자신이 만든 랜덤 데이터와 서버에서 만든 데이터를 합쳐 새로운 Pre Master Secret를 생성합니다.
6. Pre Master Secret를 서버의 공개키로 암호화하여 다시 서버에 전송합니다.
7. 서버는 개인키로 Pre Master Secret를 복호화하고 추가 데이터를 더해 Master Secret으로 저장합니다.

이렇게 생성된 Master Secret 는 Session Key를 생성하는데 사용이 됩니다. 이후로는 Session Key를 대칭키 용도로 사용이 되고 클라이언트와 정보를 교환하게 됩니다. 세션이 만료가 되면 SSL 통신이 끝났을을 알리고 Session Key는 폐기 됩니다.

 

이론적으로 보면 대칭키가 가장 안정적이라서 유저와의 소통방식에서 공개키를 넘겨주는 방식으로 처리하면 좋습니다. 하지만 이렇게 많은 인증과정을 거치면서 다시 대칭키를 만드는 이유는 공개키를 생성하게 될 때에는 많은 컴퓨터 파워를 소비하므로 지속적인 공개키 생성을 하는 전송하는 방식은 지양하고 있습니다.