게이트웨이 , HTTPS , 웹 터널이 뭔가요 ?
저번에HTTPS를 공부했었는데 이번에 공부하는 챕터에서도 같은 내용이 나와 좀 더 이해를 하고 보충적인 부분들만 적으려고 한다.
TLS / SSL 레이어
TSL(TransPort Layer Security) / SSL (Secure Sockets Layer) 는 HTTPS 를 사용 할 때 애플리케이션 레이어와 트랜스포트 레이어 사이에 존재하는 레이어이다.
기본적인 HTTP 에서는 클라이언트가 적은 정보가 TCP 레이어로 바로 내려가
적은 정보가 평문 (Plain Text) 상태로 전송이 되었다면
HTTPS 에서는 TCP 레이어로 내려가기 전 정보를 암호화 하거나 , 받은 암호화 된 정보를 복호화 하는 SSL / TLS 레이어를 거치게 된다.
TLS / SSL는 데이터의 보안을 제공하기 위해 설계된 프로토콜로 암호화와 복호활를 담당하는 레이어이다.
어떻게 암호화 하고 복호화 하나요 ?
그럼 가장 중요한 어떻게 암호화 하고 복호화 하는지에 대해 이해해보자
암호화 하고 복호화하기 위해서는 두 가지 장치가 필요할 것이다.
평문을 암호화 하는 키와 암호화 된 평문을 다시 평문으로 돌리는 키, 두 가지가 필요하다.
이 때 암호화하고 복호화 하는 키가 동일한 방법을 대칭키 시스템이라 하고
암호화하는 키와 복호화 하는키가 다른 방법을 비대칭키 시스템이라고 한다.
키들 중에서 모두에게 공유 될 수 있는 키를 공유키 (Public key) 라고 하고 다른 이들에게 유출되지 않고 개인만 가지고 있는 키를 개인키 (Private Key)라고 한다.
평문을 암호화 할 수 있는 키를 이용해 남들이 봐도 알아보지 못할 암호로 암호화 하고
받는 이는 해당 암호화 된 글을 복호화 하여 알아 볼 수 있다.
암호화 , 복호화 키 사용 예시
평문을 암호화, 복호화 하는 알고리즘은 다양하지만 가장 많이 사용되는 대칭키 알고리즘은 AES (Advanced Encryption Standard) 이다.
텍스트 암호화 사이트에서 간단하게 키값에 따른 암호화와 복호화를 체험해볼 수 있다.
1234567891123456 이라는 키를 이용해 암호화 할 수 있고
동일한 키로 암호화 된 글을 복호화 할 수도 있다.
대칭키를 이용한 보안의 단점
그럼 만약 클라이언트와 서버가 대칭키를 이용해 암호화,복호화를 한다고 생각해보자
클라이언트와 서버가 대칭키를 이용한 보안을 이용하기 위해선
서버는 클라이언트측에 암호화, 복호화 할 수 있는 키를 제공해야 한다.
결국 네트워크 상에서 서버와 클라이언트만의 보안을 위한 키가 공개적으로 통신망을 지나간다는 뜻이고
해당 키가 유출되는 순간, 보안은 의미가 없어져버리게 된다.
클라이언트가 해당 키로 이용해 암호화 시킨 데이터는
다른 사람이 해당 키로 복호화 해서 훔쳐 볼 수 있기 때문이다.
비대칭키를 이용해보자
위 예시에서 보안을 위해서는 결국 클라이언트 측으로 키를 제공해야 한다.
이렇게 모든 클라이언트들에게 제공되는 키를 공개키 라고 한다.
이전 대칭키를 이용한 보안의 문제점은 공개키 로 암호화 한 데이터가 공개키 로 복호화 할 수 있기 때문에 발생했다.
그럼 공개키 로 암호화 한 데이터는 누구나 가지고 있는 것이 아니라 서버만 가지고 있는 개인키 만으로 복호화 할 수 있게 해보자
그렇게 되면 클라이언트가 암호화 한 데이터는 네트워크에서 유출이 되더라도 서버만 가지고 있는 개인키 가 없다면 복호화 할 수 없기 때문에 대칭키 시스템에 비해 안전하다 할 수 있다.
하지만 여기서 문제가 생긴다.
그러면 , 클라이언트 -> 서버 측으로 가는 데이터는 보안이 가능하지만, 서버측 -> 클라이언트 로 가는 데이터는 보안이 불가능하다.
왜냐면 클라이언트는 서버로부터 받는 데이터를 복호화 할 수 있는 키가 존재하지 않기 때문이다.
대칭키와 비대칭키를 짬뽕시키자
그래서 대칭키와 비대칭키를 짬뽕시켜서 사용한다.
HTTPS통신에서 클라이언트는 웹 서버와 통신을 시작 할 때 임의로 발생시킨 문자열을 동반하여 전송한다.- 웹 서버는 클라이언트에게 본인의 공유키가 들은 인증서와 함께 서버측에서 임의로 발생시킨 문자열을 동반하여 전송한다.
인증서는 추후 설명하도록 하겠다.
- 그럼 지금 클라이언트는 문자열 2개와, 서버로부터 받은 공유키가 존재하고 서버도 문자열 2개와 클라이언트에게 보낸 공유키, 본인의 개인키가 존재하는 상황이다.
- 클라이언트는 서버와 주고받은 문자열 2개를 조합해 보안에 사용할 대칭키 를 만든다. 이 때 만든 대칭키를 서버에게 알려주기 위해 공유키를 이용해 사용할 대칭키를 암호화 한다.
- 서버측에서는 암호화 된 대칭키를 복호화 하여 클라이언트를 확인한다.
확인이 가능한 이유는 공유키로 암호화 된 문자열은 서버의 개인키만으로 복호화 할 수 있기 때문이다.
이렇게 확인을 통해 웹 서버 또한 자신과 통신을 주고받은 클라이언트가 정확하게 자신과 통신하고 있는 클라이언트임을 확인 할 수 있다.
- 이렇게 서버와 클라이언트는 서로가 사용할 대칭키 를 생성했고, 해당 대칭키를 이용해 주고 받는다.
정리
클라이언트와 서버가 비대칭키 시스템으로 내용을 암호화하고 복호화 하는 것은 비용이 많이 들기 떄문에 간단한 대칭키 시스템을 이용하며 이런 대칭키 시스템은 비대칭키 시스템을 이용해 공유된다.
사이트 인증서
위 예시에서 2번 단계에서 사이트 인증서 를 서버가 클라이언트 측으로 제공한다고 하였다.
사이트 인증서 (SSL 인증서) 는 해당 사이트가 신뢰할만 한지를 인증하는 민간기업 (CA)의 심사를 거친 사이트만 가질 수 있다.
대부분의 웹 브라우저에는 SSL 인증서 리스트가 존재하기 때문에 어떤 서버에서 제공한 인증서가 CA 에 의해 인증되지 않은 사이트일 경우에는, 브라우저에서 안전하지 않은 브라우저라는 문구가 뜨게 된다.
이처럼 SSL 인증서 를 사용하는 이유는 https 통신을 사용하는 안전한 서버인척 하지만 실제로는 보안이 완벽하지 않거나 믿음직스럽지 않은 서버에게 민감한 정보를 제공하지 않기 위함이다.
사이트 인증서 에는 해당 서버의 공유키를 포함해 다양한 내용들이 들어있다.
프록시가 껴있을 경우의 HTTPS 통신
HTTPS 는 헤더 내용과 엔터티 모두 암호화 시킨다.
이처럼 헤더마저 암호화 시켜버리면 키를 가지고 있지 않은 프록시들은
패킷을 받아도 어느 사이트로 보내야 할지 알 수 없다.
목적지가 적힌 헤더를 해석 할 수 없기 때문이다 .
그렇기 때문에 HTTPS 통신을 이용 하며 프록시를 지나갈 때에는
통신을 주고 받기 전 프록시에게 우선 연결하고자 하는 종단점의 주소가 담긴 패킷을 먼저 보낸다.
이 때 사용하는 메소드는 CONNECT 메소드이다 .
CONNECT 메소드를 이용해 프록시에게 다음에 보낼 패킷의 목적지를 알려준 후
암호화 된 패킷을 전송한다.
HTTPS 의 포트 번호
HTTP 통신의 암묵적인 포트 번호는 80 이였다.
HTTPS 통신의 암묵적인 포트 번호는 443 으로 통일한다.
HTTP 와 다른 포트 번호를 이용하는 이유는 HTTPS 를 사용하는 패킷들은 HTTP 에서 기대하는 패킷과는 다르게 생겼다.
암호화 되어있기 때문이다.
만일 같은 포트를 사용하게 되면 패킷이 들어왔을 때 서버는 잘못 전송된 패킷인줄 알고 폐기해버린다.
그렇기 떄문에 HTTPS 만 사용하는 포트번호가 필요했다.
