-
HTTP와 HTTPSEngineering/Network 2019. 11. 11. 22:31반응형
HTTP (HyperText Transfer Protocol)
HTTP 란 인터넷 상에서 정보를 주고 받을 수 있는 프로토콜이며, 주로 HTML 문서를 주고받는 데 많이 쓰인다. 통신 구조는 클라이언트와 서버 사이에서 요청과 응답으로 이루어져 있다. 통신은 암호화가 되지 않은 방법으로 데이터를 전송하므로 누군가가 네트워크에서 악의적인 감청을 한다면 내용이 유출된다.
이러한 평문 전송을 통한 HTTP 통신을 보완한 것이 HTTPS 이다. HTTPS 의 S 는 Over Secure Socket Layer 의 약자로, HTTP 와 디지털 암호화 기술을 결합하여 보안이 강화된 버전이다.
HTTPS 는 모든 HTTP 요청과 응답 데이터는 네트워크로 보내지기 전에 암호화된다. HTTPS 는 HTTP의 하부에 보안 계층을 제공하여 동작하는데, 이 계층은 SSL(Secure Socket Layer) 또는 TLS(Transport Layer Security)를 이용하여 구현된다.
SSL 과 TLS 는 사실 같은 말이며, 초창기에는 넷스케이프에 SSL이 발명되었고, 이것이 점차 널리 사용되면서 표준화 기구인 IETF에 의해 표준화 되었으며, TLS 라는 명칭으로 변경되었다.
SSL 디지털 인증서
디지털 인증서는 신뢰할 수 있는 기관으로부터 보증 받은 사용자나 회사에 대한 정보를 담고 있는 전자 문서이다. 이 인증서는 클라이언트와 서버간의 통신을 제 3자가 보증해준다. SSL 디지털 인증서를 통해서 우리는 다음과 같은 기능을 얻을 수 있다.
- 통신의 내용을 암호화한다.
- 클라이언트는 접속하려는 서버가 신뢰할 수 있는 서버인지 판단할 수 있게 된다.
- 암호의 체크섬을 통해 메시지의 위조를 방지할 수 있다.
CA (Certificate Authority)
인증서의 역할은 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지 보장하는 역할을 한다. 이러한 역할을 하는 기업들을 CA라고 한다. CA는 신뢰성이 엄격하게 공인된 기업들만이 참여할 수 있다.
SSL 인증서에는 다음을 포함한 많은 필드를 갖고 있다.
- 서버의 이름과 호스트명
- 서버의 공개키
- 서명 기관의 이름
- 서명 기관의 서명
서비스의 도메인, 공개키와 같은 정보는 서비스가 CA 로부터 인증서를 구입할 때 제출해야한다. 위와 같은 내용들은 CA 에 의해 암호화 되는데, 이 때 사용하는 암호화 기법이 공개키 방식이다. CA 는 서버의 공개키, 공개키의 암호화 방법 등의 정보를 담은 인증서를 만들고, 해당 인증서를 CA 의 개인키로 암호화하여 서버에게 제공한다. 브라우저는 배포될 때, 공인된 CA 의 인증서가 미리 설치된 채로 배포되기 때문에 각 CA 의 공개키를 미리 알고 있다. 이로써 서버는 SSL 인증서를 갖게된다.
사용자는 HTTPS 를 통한 웹 트랜잭션을 시작할 때, 최신 브라우저는 자동으로 접속한 서버에서 디지털 인증서를 가져온다. 브라우저가 인증서를 받으면, 서명 기관을 검사하여 그 기관이 신뢰할 수 있는 공인된 서명 기관이라면 브라우저에 미리 내장된 공개키를 이용하여 인증서를 복호화한다. 이 과정을 통해 클라이언트는 서버의 공개키를 얻을 수 있게 된다.
SSL 의 동작 방법
클라이언트와 서버가 통신을 할 때, 가장 이상적인 방법은 공개키 방식이지만, 공개키 방식은 암호화하고, 복호화하는 과정에서 많은 자원을 사용해야 하기 때문에 성능상의 단점이 있다. 그래서 공개키와 대칭키를 함께 사용한다.
클라이언트와 서버가 주고 받는 실제 정보는 웹 브라우저가 대칭키를 생성하여 암호화하고, 인증서에서 얻은 공개키로 대칭키를 암호화하여 웹 서버로 전송한다. 웹 서버는 자신이 가지고 있는 개인키로 클라이언트가 보낸 대칭키를 복호화하여 데이터를 주고 받는다.
SSL 의 통신 과정
컴퓨터와 컴퓨터가 네트워크 통신을 할 때, 내부적으로 3가지 단계를 거친다.
핸드쉐이크 -> 세션 -> 세션종료
1. 핸드쉐이크 (Handshake)
암호화된 HTTP 메시지를 보낼 수 있게 되기 전에, 클라이언트와 서버는 SSL 핸드쉐이크를 한다. 핸드쉐이크에서는 다음과 같은 일이 일어난다.
- 프로토콜 버전 번호 교환
- 양쪽이 알고 있는 암호 선택
- 양쪽의 신원을 인증
- 채널을 암호화하기 위한 임시 세션 키 생성
핸드쉐이크 과정
(생활코딩의 이고잉님께서 정말 자세하게 설명해주셨습니다. 더 자세한 내용은 아래의 링크를 참조하시면 좋습니다.)
https://opentutorials.org/course/228/4894
1. 클라이언트가 서버에 접속한다. 이 단계를 Client Hello 라고 한다. 이 단계에서 주고 받는 정보는 아래와 같다.
- 클라이언트 측에서 생성한 랜덤 데이터
- 클라이언트가 지원하는 암호화 방식들
- 세션 아이디 : 이미 SSL 핸드쉐이킹을 했다면 기존의 세션을 재활용 하는데, 이 때 사용할 연결에 대한 식별자를 서버에 전송한다.
2. 서버는 Client Hello 에 대한 응답으로 Server Hello 를 하게 된다. 이 단계에서 주고 받는 정보는 아래와 같다.
- 서버 측에서 생성한 랜덤 데이터
- 서버가 선택한 클라이언트의 암호화 방식
- 인증서
3. 클라이언트는 서버로부터 받은 인증서를 내장된 CA 의 공개키를 이용하여 복호화하고, 서버 측의 공개키를 얻는다. 클라이언트는 1번 과정에서 생성한 랜덤 데이터와 2번 과정에서 서버로부터 받은 랜덤 데이터를 조합하여 pre master secret 라는 키를 생성한다. 이 키를 서버 측의 공개키로 암호화하여 서버로 전송한다.
4. 서버는 클라이언트가 보낸 pre master secret 값을 자신의 비공개키로 복호화한 후, 클라이언트와 일련의 과정을 거쳐서 pre master secret 값을 master secret 값으로 만든다. master secret 는 session key 를 생성하는데, 이 session key 값을 이용해서 서버와 클라이언트는 데이터를 대칭키 방식으로 암호화 한 후에 주고 받게 된다.
5. 서버와 클라이언트는 핸드쉐이크 단계의 종료를 서로에게 알린다.
2. 세션 (Session)
이 단계는 핸드쉐이크 과정에서 생성한 session key 를 이용하여 데이터를 대칭키 방식으로 암호화하여 클라이언트와 서버가 데이터를 주고 받는 단계이다.
3. 세션 종료
데이터의 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알려준다. 이 때 통신에서 사용한 대칭키인 session key 를 폐기한다.
참고 자료
https://opentutorials.org/course/228/4894
https://jeong-pro.tistory.com/89
https://offbyone.tistory.com/274
HTTP 완벽 가이드, 데이빗 고울리 저 <<인사이트 출판사>>
반응형'Engineering > Network' 카테고리의 다른 글
[Network] 공유기가 인터넷과 통신하는 방법 (feat. NAT) (0) 2020.10.22 [Network] 패킷의 전달 과정 (Youtube Link) (0) 2020.10.19 [Network] TCP/IP 모델 패킷 전송 과정 (0) 2020.10.14 [Network] 로드밸런싱 (Load Balancing) (0) 2020.10.12 DNS 서버에 대하여.. (0) 2019.12.05