HTTPS와 SSL, 그리고 공개키에 관한 총정리 #TLS #공개키 #대칭키

오늘은 웹기술에 있어서 매우 중요한 HTTPS를 이해하기 위해서,

HTTPS와 TLS/SSL 그리고 이에 사용되는 공개키 알고리즘에 대해서 정리해 보도록 하겠습니다.

1. HTTP

HTTP는 Hyper Text Transfer Protocol의 약자인데요.

Protocol이라는 것은 네트워크를 통해서 컴퓨터간에 데이터를 이용해 정보를 주고 받을 때,

정해진 순서나 문법을 말합니다.

여기에 사용되는 HTTP메세지는 크게 두가지가 있는데요.
Request와 Response가 바로 그것입니다.

Request와 Response의 과정을 좀 더 구체적으로 보면,

만약 유저가 특정주소를 입력하면,

브라우저는 해당 페이지에 필요한 컨텐츠를 보여주기 위해,

아래와 같은 HTTP GET리퀘스트를 보내구요. 서버는 이에 Response로서 필요한 컨텐츠를 다시 보내주지요.

GET /test.txt HTTP/1.1
User-Agent: Mozilla/5.0 
Host: www.test.com
Accept-Language: en

 

이번에는 Response 메세지를 한번 보도록 하겠습니다.

HTTP는 보통 이러한 텍스트메시지로 정해진 규약에 따라서 Response메세지를 보냅니다.

HTTP/1.1 200 OK
Date: Tue, 3 Feb 2020 12:14:39 GMT
Server: Apache
Last-Modified: Sun, 1 Feb 2020 11:17:01 GMT
Accept-Ranges: bytes
Content-Length: 24
Vary: Accept-Encoding
Content-Type: text/plain

 

2. HTTPS

HTTPS의 마지막 S는 Secure를 의미하는데요.

HTTPS는 위에서 HTTP가 하는일을 똑같이 하지만,

TLS(또는 SSL)을 Request와 Response를 암호화 하기 위해 사용한다는 점이 다릅니다.

위에서 예를 들었던, HTTP메시지는 아무나 읽을 수 있는 Text라는 점에서 보안상 위험할 수 있는데요.

특히 유저가 카드번호같은 민감한 정보를 입력할 경우,

Request와 실린 Text 정보를 누구나 읽을 수 있게 되겠지요.

 

위에서 Get Request의 예를 텍스트로 보여주었었는데요.

HTTPS를 사용한다면,  아래와 같이 그냥 랜덤한 암호화된텍스트를 보게 됩니다.

HTTP와는 달리 정보가 노출될 가능성이 매우 낮아집니다.

rtew89w9fsw9fuw724++3-2fsfswf2242923e90f0++-3-2fpwu02fj02rp23ort2p3jktp23jo

 

그럼 HTTPS를 이해하기 위해서, 여기에 사용되는 공개키 알고리즘에 대해서 알아보도록 하겠습니다.

 

2-1. 공개키 알고리즘

TLS/SSL은 공개키암호화 기술을 사용하는데요.

이 기술을 사용하기 위해서는 두개의 Key가 사용되어집니다.

모두에게 공개된 Public Key와 공개되지 않은 Private Key인데요.

 

이 알고리즘의 중요한 핵심은,

Public Key를 통해서 암호화 된 데이터는 Private Key가 있어야만 해독할 수 있구요.

반대로 Private Key로 암호화 된 데이터는 Public Key가 있어야만 해독할 수 있게 되어 있는데요.

이렇게 암호와 해독을 스스로 해결할 수 없음으로서,

Public Key가 노출되더라도 해독을 할 수 없는, 비대칭적 구조를 형성해서 보안성을 높이는 방법이라는 것 이지요.

 

어떻게 이런방식이 가능한 것 일까요?

이것을 비유적으로 이해해 보도록 하겠습니다.

만약 보석가게를 하는 박씨와 송씨가 보물상자에 보석을 넣고 열쇠를 잠그려고 합니다.

보통 자물쇠는 Lock상태와 UnLock상태만 있겠지요.

그래서 이 Key를 훔치거나 이 Key를 복사한 후에 몰래 제자리에 두면,

뒷집의 홍씨도 이 보물상자를 열수 있게 되는데요.

보석가게를 하다보면, 손님이 와서 보석을 맡길경우,

어쩔 수 없이 보물상자를 사람들이 있을 때,

낮에 장사를 하는 박씨가 열어보아야 하니, 더욱 위험하긴 합니다.

대칭적인 암호화 혹은 대칭키가 이런 것 이겠지요. 암호화 해독을 하나의 키로 할 수 있는 상태말이지요.

 

 

그래서 송씨가 아이디어를 냅니다.

아래 이미지와 같은 3가지 상태를 만드는 것 인데요.

아래 이미지와 같이 B일 경우에만 열 수 있도록 하자는 것 이지요.

여기에다가, Key에도 한가지 방법을 더 합니다.

두 개의 Key를 만들어서 1번 Key는 왼쪽으로만,

2번 Key는 오른쪽으로만 열리게 하는 것 이지요.

그럼 1번 Key로 잠갔을 경우, 2번 Key로만 열리게 하는 것 인데요.

 

이렇게 해서 비대칭적인, A로 잠그면, B로만 열수 있는 상태가 생성된 것 이지요.

 

 

이러한 상태가 형성되면,

보물을 넣어두어야 하는 박씨가 Public Key로 사용할 1번 Key 로 잠구면,

이것을 열 수 있는 사람은 Private Key를 소유한 송씨만 가능하다는 것을 알 수 있지요.

동시에 박씨이외에 보석가게에 점원을 몇 명 두고 그들에게 이 1번 Key를 줄 수도 있겠습니다.

왜냐하면 보석상자는 1번 Key로는 잠굴수만 있기 대문입니다.

 

또한, 만약 송씨가 박씨에게 보석을 판 돈을 전달하고자 해서

그의 Private한 2번 Key로 다시 보물상자를 잠궜다면,

이것이 잠구어진 상태가 C에 가 있을 것이므로,

박씨는 다른 누군가가 아닌 송씨가 잠군것을 확인할 수 있고,

곧 자신의 공개키인 1번 Key로 왼쪽으로 열어서 돈을 받을 수 있겠지요.

 

2-2. HTTPS와 공개키 알고리즘

위의 공개키 알고리즘을 HTTPS에서는 다음과 같이 사용하고 있습니다.

유저가 웹사이트에 접속하게 되면, Website의 SSL인증서가 공개되어 지는데요.

이 인증서에는 웹사이트의 소유자에 대한 정보와 Public Key가 포함되어 있습니다.

누구나 접속하면 public key에 접근할 수 있는 것 이지요.

대신 Private Key는 안전하게 구성된 Server에 존재합니다.

 

Client가 서버에 접속하면,

위에서 언급한 공개키 알고리즘을 이용해서, TLS HandShake가 발생합니다.

즉, 두개의 다른 키를 이용해서 커뮤니케이션을 하는 것 인데요.

TLS Handshake가 시작되면, 서버와 클라이언트가 각자의 Private키와 Public키로 생성한 데이터를 이용해서,

Session Keys라고 하는 암호화와 해독이 가능한 새로운 Key를 만들어 내고,

private키와 public키는 더 이상 사용되지 않습니다.

 

공개된 public key와 서버의 private key를 이용해서 새로운 대칭키인 Session Key를 만들어,

정해진 시간동안만 이 Key로 추가적인 정보교환에 이 키를 사용하게 됩니다.

 

 

A. Why Session Key?

Session Key와 같은 대칭키를 만들면 위험한 것 아닌가 하는 생각이 들 텐데요.

이 Session키는 임시적인 키로서, 한번 Session이 끝나면, 더이상 사용할 수 없습니다.

Session에 대한 Timeout은 서버에서 설정 할 수 있는데요.

보통은 30분 정도로 잡는데, 어떤 애플리케이션인지 또는 어떤 상황인지에 따라서 다르겠지요.

 

B. TLS와 SSL

위에서도 계속 TLS와 SSL이라는 이름이 혼용되어 지고 있는데요.

SSL은 Secure Sockets Layer의 약자이구요.
HTTP를 위해서 개발되었던 암호화 Protocol입니다.

이것은 Transport Layer Security의 약자인 TLS에 의해서 대체되었는데요.
사실상 이제 SSL이라는 이름이 필요하지 않지만,

SSL이라는 이름이 계속 사용되어지고 있습니다.

 

3. SSL 인증서

3-1. SSL 인증서

위에서도 언급하였던 SSL인증서에 대해서도 정리해 보겠습니다.

SSL인증서는 공인할 수 있는 제3자인 CA(certificate authority) 기관이

서버와 클라이언트간의 통신을 보증하여 주는 전자 문서입니다.

 

유저가 브라우저를 통해 서버에 접속하면 이 인증서를 브라우저에 전달해 줍니다.

 

이 인증서에는 다음과 같은 여러가지가 정보가 담겨있는데요.

이 중에서도 가장 중요한 정보는 Public Key이겠지요.

• Domain Name과 Subdomain Name
• 인증서가 발급된 소유자 혹은 단체에 대한 정보
• 인증기관과 디지털 사인
• 발급일과 인증 유효일
• Public Key

그러면 브라우저는 위의 정보들을 이용해서,

이 인증서가 신뢰할 수 있는지 검증하게 되는 것 인데요.

단순히 HTTPS통신의 공개키 알고리즘과 Session Key를 이용하는 것 뿐만이 아니라,

이 인증서를 이용해 제3자의 보증을 통해서 악의적인 도메인 소유자가 아닌지 확인하는 과정까지하게 됩니다.

 

실제로 인증서는 일정요건을 맞추어서 개인도 만들어서 서버에 넣을 수는 있지만,

인정받은 CA(certificate authority)가 아니라면,

브라우저는 위험한 사이트 일 수 있다는 경고를 띄우게 됩니다.

이상으로 HTTPS와 SSL 그리고 공개키와 대칭키등에 대해서 알아보았구요.

좀 더 좋은 정보가 있으면 이 글을 통해서 업데이트 하도록 하겠습니다.