프론트엔드Explorer

HTTPS, 대칭키, 공개키, CA에 대해 모른다면 아래 포스팅을 참고해보자. 

https://dolphinsarah.tistory.com/52

SSL은 아래 3가지 액션으로 인해 동작하게 된다. 

• 악수(handshake)
• 데이터 전송
• 세션 종료

악수(handshake)

클라이언트, 서버 간의 통신을 하기 전 실제 통신을 할 수 있는지, 서로 검토하는 단계이다. 

사람이 처음 만나면 악수를 하듯이, 클라이언트와 서버도 비슷하다. 

클라이언트가 서버에 처음 접속하게 되는 시점, 단계를 Client Hello라고 한다. 

또한, 서버는 Client Hello에 대한 응답으로 Server Hello를 하게 된다. 

Client Hello 단계

• 클라이언트에서 랜덤 데이터를 생성한다. 
• 클라이언트에서 사용할 수 있는 암호화 방식들을 서버에 전달한다. 
• 클라이언트에서 사용되는 암호화 방식과 서버에서 가능한 암호화 방식이 다를 수 있기 때문에, 두 군데 모두 사용할 수 있는 암호화 방식에 대해 협상이 필요하다. 

Server Hello 단계

• Client Hello에 대한 응답 과정이다. 
• 클라이언트와 동일하게 랜덤 데이터를 생성하며, 클라이언트에 전달한다. 
• 클라이언트가 전달한 암호화 방식 중에서 서버 쪽에서도 사용할 수 있는 암호화 방식을 선택해서 클라이언트로 전달한다. 채택된 암호화 방식으로 클라이언트-서버 간 통신이 진행된다. 물론 클라이언트에서 보내준 암호화 방식을 서버에서 지원하지 않는다면, 암호화 협상 결렬로 인해 악수는 불발된다. 
• 서버가 발급받은 인증서를 클라이언트로 전달한다. 

Client 인증 단계

• 클라이언트는 서버의 인증서가 CA에 의해서 발급된 것인지를 확인하기 위해 클라이언트에 내장된 CA 리스트를 확인한다. CA 리스트에 인증서가 없다면 사용자에게 경고 메시지를 출력한다. 인증서가 CA에 의해서 발급된 것인지를 확인하기 위해 클라이언트에 내장된 CA의 공개키를 이용해서 인증서를 복호화한다. 복호화에 성공했다면 인증서는 CA의 개인키로 암호화된 문서임이 암시적으로 보증된 것이다. 인증서를 전송한 서버를 믿을 수 있게 된 것이다. 
• 클라이언트는 Server Hello 단계에서 받은 랜덤 데이터와 Client Hello 단계에서 생성한 랜덤 데이터를 조합하여 pre master secret 키를 생성한다. 이 키는 데이터를 주고받을 때 사용하기 위한 암호화 키이며 대칭키 방식으로 사용되어질 키 값이다. 중요한 키임으로 절대 제 3자에게 노출되면 안된다. 그렇기 때문에 이 pre master secret 키 값을 서버에게 전달할 때 서버가 제공한 공개키로 암호화 하여 전송하며, 서버는 자신의 비공개키로 복호화하여 pre master secret 값을 취득한다. 클라이언트가 사용한 공개키는 Server Hello 단계에서 전달받은 인증서 안에 들어있다. 

Server 인증 단계

• 서버는 클라이언트가 전송한 pre master secret 값을 자신의 비공개키로 복호화한다. 이제 서버와 클라이언트 모두 pre master secret 값을 공유하게 되었다. 
• 서버와 클라이언트는 모두 일련의 과정을 거쳐서 pre master secret 값을 master secret 값으로 만든다. 
• master secret은 session key를 생성하는데, 이 session key 값을 이용해서 서버와 클라이언트는 데이터를 대칭키 방식으로 암호화 한 후에 주고받는다. 이렇게 해서 세션키를 클라이언트와 서버가 공유하게 된다. 

악수(handshake) 종료

• 위의 과정으로 클라이언트와 서버는 악수 단계의 종료를 서로에게 공유한다. 

데이터 전송

: 실제로 서버와 클라이언트가 데이터를 주고 받는 과정이다. 상대방에게 데이터를 송신하기 전, 악수 단계에서 발생한 세션 키 값으로 데이터를 대칭키방식으로 암호화한다. 

암호화된 데이터는 상대방으로 송신되며, 상대방도 세션키를 알고 있기 때문에 데이터를 복호화할 수 있다. 

SSL 통신은 공개키 방식, 대칭키 방식의 하이브리드 조합으로 통신한다. 

공개키 방식은 컴퓨터 자원을 꽤 많이 사용함으로 비용이 많이 드며, 또한 대칭키 방식만 사용하게 되면 인터넷 상 대칭키를 서로 주고받아야 하는데, 보안상 매우 위험하다.

그래서 속도는 느리지만 데이터를 안전하게 주고 받을 수 있는 공개키 방식으로 대칭키를 암호화하고, 실제 데이터를 주고 받을 때는 대칭키를 이용해서 데이터를 주고 받는 것이다. 

세션 종료

: 데이터 송수신이 끝나면 SSL 통신이 끝났음으로 서로에게 알려준다. 

이때, 통신에서 사용한 세션키(대칭키)를 폐기한다. 

HTTP에 보안처리(SSL)가 된 버전이 HTTPS이다. (요즘은 HTTPS가 웹의 기본 스펙이라고 봐도 무방함)

HTTPS는 기존 HTTP 레이어에서 SSL 또는 TLS 프로토콜을 얹어 평문 데이터를 암호화하고,  

암호화, 인증, 그리고 무결성 보장을 통해 더 안전히 만들어주는 프로토콜이다. 

SSL과 TLS

SSL(Secure Sockets Layer)은 TLS(Transport Layer Security)의 과거 명칭이라고 봐도 무방하다. 

TLS는 SSL 3.0을 기초로 해서 IETF가 만든 프로토콜이다. 

TLS는 SSL 3.0을 보다 안전하게 하고, 프로토콜의 스펙을 더 정확하게 안정성을 높이는 목적으로 고안하였다. 

SSL이나 TLS를 통해 평문을 암호화하고, 복호화할 때,

대칭키나 공개키 방식을 사용하는데 이에 대해 알아보자. 

대칭키

대칭키 암호화 방식은 집 열쇠와 같다고 생각하면 된다. 

대칭키를 가지고 데이터를 암호화하고, 또 대칭키로 데이터를 복호화한다. 

예를 들어 'abc'라는 키로 데이터를 암호화했다면, 데이터를 복호화하기 위해서는 반드시 'abc' 키가 필요하다. 

즉, 클라이언트와 서버가 대칭키 방식으로 통신을 한다면, 클라이언트도 키를 가지고 있어야 한다. 

그런데 대칭키 방식은 치명적인 단점이 있다. 

암호를 주고 받는 사이에서 대칭키를 전달하는 것이 어렵고, 

만약, 중간에 대칭키가 탈취 또는 유출되면 그 키로 암호화 되었던 데이터들은 모두 유출된다. 

즉, 원거리에서 대칭키를 안전하게 전달하는 것은 매우 어렵다. 

이러한 대칭키의 단점을 극복하고자 나온 방식이 공개키 방식(PKI, Public Key Infrastructure)이다.

공개키(비대칭키)

공개키 방식은 공개키와 개인키(비밀키)라는 2가지의 비대칭키를 가진다. 

만약, A키로 암호화하면 B키로 복호화 가능하며, 반대로 B키로 암호화하면 A키로 복호화가 가능하다. 

A와 B 중 하나는 공개키(public key)가 되고, 나머지 하나는 비공개키(private key)가 된다. 

비공개키는 소유자, 즉, private한 사용자가 가지고 있게 되며, 

공개키는 소유자와 타인에게 공개되는 키이다. 

타인이 공개키를 이용하여 데이터를 암호화해 소유자에게 전달하면, 

소유자는 비공캐기로 복호화하여 그 데이터를 얻을 수 있게 된다. 

이 방식은 안전하게 데이터를 주고받을 수 있게 만들어주지만, 속도가 느리다는 단점이 있다. 

전자서명

비공개키의 소유자는 비공개키를 이용해서 정보를 암호화 한 후에 공개키와 함께 암호화된 정보를 전송한다. 

정보와 공개키를 획득한 사람은, 공개키를 이용해 암호화된 정보를 복호화한다. 

이 과정에서 공개키가 유출된다면 의도하지 않은 공격자에 의해 데이터가 복호화될 위험이 있다. 

이런 위험에도 불구하고 비공개키를 이용해 암호화를 하는 이유가 뭘까? 

비공개키는 데이터를 보호하는 것이 목적이 아니다. 

암호화된 데이터를 공개키를 가지고 복호화할 수 있다는 것은 그 데이터가 공개키와 쌍을 이루는 비공개키에 의해서 암호화되었다는 것을 의미한다. 

즉, 공개키가 데이터를 제공한 사람의 신원을 보장해주는 것이다. 이러한 것을 전자서명이라고 부른다.

SSL 인증서와 CA(Certificate Authority)

SSL을 적용하기 위해서는 인증서가 필요하다. 

SSL 인증서는 아래의 2가지를 제공한다. 

• 클라이언트가 접속한 서버가 신뢰 있는 서버임을 증명(인증서 발급 CA, 도메인 등)한다. 즉, 클라이언트가 접속한 서버가 클라이언트가 목적한 서버가 맞는지 확인한다. 
• SSL 통신에 사용될 공개키를 클라이언트에 제공(서버 공개키)한다. 서버와 클라이언트가 통신할 때 사용될 공개키와 공개키 암호화 방법들의 정보가 있다. 

CA는 이 SSL 인증서를 발급해주는 기업이다. 

인증서가 보안에 관련된 것인만큼 CA는 신뢰할 수 있는 기업에서만 가능하다. 

SSL 인증서 및 내용은 CA에 의해서 암호화된다. 이때 CA는 자신의 비공개키로 서버가 제출한 인증서를 암호화한다. 

CA의 비공개키는 절대로 유출되어서는 안되며, 실제로 디지노타라는 회사에서 CA의 비공개키가 유출된 사례가 있어 CA 자체가 파산된 경우도 있다고 한다. 

브라우저와 CA

브라우저는 내부적으로 CA의 리스트를 미리 알고 있다. 

즉, 브라우저 소스 안에 CA 리스트가 존재한다는 말이다. 

CA 리스트 뿐만 아니라, 각 CA의 공개키도 이미 브라우저 안에 내장되어 있다. 

브라우저가 서버에 접속할 때, 서버는 클라이언트에게 인증서를 제공한다. 

브라우저는 서버에서 받은 인증서가 자신이 가지고 있는 CA 리스트에 있나 확인을 한다. 

비교 후 정상적인 인증서이면, 해당 CA의 공개키(브라우저 안에 있는)를 이용하여, 인증서를 복호화한다. 

복호화가 됐다면, 그 인증서는 CA의 비공개키로 암호화된 것을 의미한다.

즉, 해당 CA에 의해 정상적으로 발급된 인증서라는 의미가 되며, 그것은 클라이언트가 접속한 서버에서 제공한 인증서가 해당 CA에 의해 정상적으로 발급됐다는 의미이다. 

=> 클라이언트가 접속한 서버에서 받은 인증서가 CA에서 정상적으로 발급된 인증서이다. 

다음 포스팅에서는 HTTPS의 동작 원리에 대해 알아보도록 하자. 

https://dolphinsarah.tistory.com/53

프록시(Proxy)는 대신해준다는 뜻이다. 

프록시는 여러 곳에서 쓰이는데, 디자인 패턴 중에도 프록시 패턴이 있고, 자바스크립트에서도 프록시 객체가 쓰인다. 

오늘 알아볼 포워드 프록시(Forward Proxy)와 리버스 프록시(Reverse Proxy)는 프록시 서버다. 

프록시 서버는 클라이언트나 서버를 대신해 인터넷과 연결한다. 

프록시의 위치에 따라 포워드 프록시와 리버스 프록시로 구별되기도 하고, 

사용하는 프로토콜에 따라 HTTP 프록시, SOCKS 프록시 등으로 구분하기도 한다. 

HTTP 프록시는 일반적으로 HTTP와 HTTPS 프로토콜들을 연결한다. 

SOCKS 프록시는 Socket Secure인데 클라이언트와 네트워크가 패킷을 교환할 때, FTP, HTTP, SMTP 등의 여러 프로토콜을 받을 수 있다. 

포워드 프록시(Forward Proxy)

포워드 프록시는 클라이언트, 즉, 사용자들을 대신해 인터넷과 연결한다. 

좀 더 와닿게 설명하자면, 

웹브라우저나 토렌트 같은 곳에 프록시를 설정해주면 그 프록시를 통해서 데이터를 주고 받는다. 

즉, 포워드 프록시란 '목적지에 직접 접근하지 않고 프록시를 통해 데이터를 주고 받기 위해 사용하는 프록시'이다. 

아이패드나 아이폰은 와이파이 연결 정보에서 자체적으로 포워드 프록시 정보를 설정할 수 있도록 제공한다고 한다. 

만약, 아이폰에서 포워드 프록시를 설정한 뒤 인터넷을 사용한다면, 

아이폰이 와이파이를 통해 직접 외부 서버에 데이터를 요청하는 것이 아니라, 

포워드 프록시로부터 간접적으로 원하는 서버의 데이터를 받아오게 된다. 

프록시 서버는 네트워크 계층의 여러 곳에 존재할 수 있다. 

인트라넷을 묶어서 프록시를 통해 인터넷과 연결시킬 수도 있고, 여러 유저들이 프록시 서버를 이용해 인터넷에 접속할 수도 있다. 

포워드 프록시를 이용해서 얻는 이점은 다음과 같다. 

속도

프록시 서버는 여러 사용자들의 요청을 캐싱한다. 

초기에는 캐싱으로 인한 속도 향상을 기대하고 프록시 서버를 사용했지만, 

집집마다 초고속 인터넷이 되는 요즘 시대에 큰 이점이라고 하기는 어렵지만.... 초기에는 이점이었다!

검열

초등학교 컴퓨터실에서 특정 사이트에 들어가려고 하면 막혀 있는 경우가 있다.

프록시 서버를 사용했기 떄문이다. 

또, 회사 컴퓨터는 외부 이메일을 막아 보안 기능으로 활용한다. 

이것이 가능한 것은 프록시가 필터 기능과 트랜스코드를 할 수 있기 때문이다. 

프록시 서버는 사용자를 검열, 보안, 감시할 수 있다. 

익명성

프록시는 사용자의 요청을 대신 처리하기 때문에 IP 우회가 가능하다. 

IP 주소를 숨기긴 하지만, 데이터를 암호화하지 않는다. (VPN은 한다.)

VPN

: Virtual Private Network, 가상 사설망이다. 프록시에 보안을 더했다고 보면 된다.

vpn은 망 내에서 일어나는 모든 과정을 암호화한다. 그래서 일반 프록시보다는 훨씬 안전하다. 

(물론 vpn 운영자가 나쁜 마음을 먹을 경우는 결코 안전하다고 말할 수 없다)

리버스 프록시(Reverse Proxy) 

리버스 프록시는 포워드 프록시와는 반대로 서버를 대신해 인터넷과 연결한다. 

즉, 다른 서버의 정보를 프록시를 통해 받아오는 부류의 프록시를 뜻한다.

단, 포워드 프록시와는 다르게 사용자가 요청하는 Endpoint(서버 요청 url)는 접근하고자 하는 최종 목적지 서버가 아닌, 리버스 프록시가 된다. 

보통 HA(High Availability)를 위한 Load Balancing이나 보안상의 이유로 쓰이는 것이 일반적인데, 

리버스 프록시의 back-end 단에 여러 개의 서비스 서버를 배치하고, 

사용자의 요청을 리버스 프록시를 통해 분산할 때 유용하게 쓰일 수 있기 때문이다. 

보안 상의 이유로 직접 내부망 서버들, 즉 back-end 단의 서버에 접근하는 것을 

원하지 않을 때 DMZ와 같은 네트워크 zone에 리버스 프록시를 구성함으로써

간접적으로 서버에 접근하는 용도로 쓰일 수도 있다. 

대표적인 리버스 프록시로는 nginx, apache 웹서버 등이 있다. 

haproxy도 비슷한 의미의 리버스 프록시라고 볼 수 있으며, 

도커 엔진이 자체적으로 제공하고 있는 도커 스윙 모드 서비스의 Virtual IPs를 이용한 요청 분산도 같은 맥락이라고 볼 수 있다. 

리버스 프록시를 이용해 얻는 이점은 아래와 같다.

검열

포워드 프록시와 마찬가지로 필터링 기능을 이용해 검열이 가능하다.

유저의 IP를 확인하고 접속을 허용한다. 

분산부하

큰 서비스들은 서버를 여러 대 사용한다. 

이때, 리버스 프록시는 쏟아지는 트래픽을 여러 대의 서버로 분산해주는 '로드밸런싱'을 해준다.