[CS study] - 2

HTTP & HTTPS

 

• HTTP(HyperText Transfer Protocol)인터넷 상에서 클라이언트와 서버가 자원을 주고 받을 때 쓰는 통신 규약

 

HTTP는 텍스트 교환이므로, 누군가 네트워크에서 신호를 가로채면 내용이 노출되는 보안 이슈가 존재하는데, 이런 보안 문제를 해결해주는 프로토콜이 'HTTPS'

 

• HTTPS(HyperText Transfer Protocol Secure)인터넷 상에서 정보를 암호화하는 SSL 프로토콜을 사용해 클라이언트와 서버가 자원을 주고 받을 때 쓰는 통신 규약

HTTPS는 텍스트를 암호화한다. (공개키 암호화 방식으로!) : 공개키 설명

HTTPS 통신 흐름

1. 애플리케이션 서버(A)를 만드는 기업은 HTTPS를 적용하기 위해 공개키와 개인키를 만든다.
2. 신뢰할 수 있는 CA 기업을 선택하고, 그 기업에게 내 공개키 관리를 부탁하며 계약을 한다.

CA란? : Certificate Authority(인증기관)로, 공개키를 저장해주는 신뢰성이 검증된 민간기업

1. 계약 완료된 CA 기업은 해당 기업의 이름, A서버 공개키, 공개키 암호화 방법을 담은 인증서를 만들고, 해당 인증서를 CA 기업의 개인키로 암호화해서 A서버에게 제공한다.
2. A서버는 암호화된 인증서를 갖게 되었다. 이제 A서버는 A서버의 공개키로 암호화된 HTTPS 요청이 아닌 요청이 오면, 이 암호화된 인증서를 클라이언트에게 건내준다.
3. 클라이언트가 main.html 파일을 달라고 A서버에 요청했다고 가정하자. HTTPS 요청이 아니기 때문에 CA기업이 A서버의 정보를 CA 기업의 개인키로 암호화한 인증서를 받게 된다.

CA 기업의 공개키는 브라우저가 이미 알고있다. (세계적으로 신뢰할 수 있는 기업으로 등록되어 있기 때문에, 브라우저가 인증서를 탐색하여 해독이 가능한 것)

1. 브라우저는 해독한 뒤 A서버의 공개키를 얻게 되었다. 이제 A서버와 통신할 대는 얻은 A서버의 공개키로 암호화해서 요청을 날리게 된다.

 

HTTPS도 무조건 안전한 것은 아니다. (신뢰받는 CA 기업이 아닌 자체 인증서 발급한 경우 등)

이때는 HTTPS지만 브라우저에서 주의 요함, 안전하지 않은 사이트와 같은 알림으로 주의 받게 된다.

 

- HTTP(hypertext transfer protocol)에 대해

웹은 크게 4가지 요소로 이루어져 있다. [웹을 구성하는 중요 요소]

1. 웹페이지를 만드는 html

2. 원하는 웹페이지에 방문할 수 있도록 도와주는 주소체계인 url, uri

3. 웹페이지를 주고 받는 소프트웨어인 web browser, web server

4. 웹브라우저와 웹서버가 통신할 때 사용하는 통신 규칙인 HTTP

 

현재의 http 프로토콜은 html의 text만 다루지 않고, 이미지/동영상/오디오 등 다양한 멀티미디어 파일을 전송하는 매우 중요한 프로토콜이 되었다.

 

html, css, js, 이미지와 같은 파일은 서로가 주고 받는 콘텐츠라면, 콘텐츠를 주고 받기 위해 서버와 클라이언트 서로가 알아들을 수 있는 메시지를 정한 것이 http이다. → http는 크게 request와 response의 메시지로 이루어져있다.

Q 웹브라우저는 어떤 기계인가?

= 사용자가 요청한 정보를 웹서버에게 대신 물어봐주는 (위의 사진과 같은 text로 == header),

웹서버의 응답 헤더를 기반으로 화면에 그려주는 것

Q 웹서버는 어떤 기계인가?

= 자기가 가지고 있는 정보를 보내주면서 사진과 같은 응답 헤더를 만들어주는 기계

 

http request header format

 

http response header format

 

#참고 강의

 

+

대칭키 & 공개키

 

대칭키(Symmetric Key)

암호화와 복호화에 같은 암호키(대칭키)를 사용하는 알고리즘

동일한 키를 주고받기 때문에, 매우 빠르다는 장점이 있음

but, 대칭키 전달과정에서 해킹 위험에 노출

 

공개키(Public Key)

암호화와 복호화에 사용하는 암호키를 분리한 알고리즘

자신이 가지고 있는 고유한 암호키(비밀키)로만 복호화할 수 있는 암호키(공개키)를 대중에 공개함

공개키 암호화 방식 진행 과정

1. A가 웹 상에 공개된 'B의 공개키'를 이용해 평문을 암호화하여 B에게 보냄
2. B는 자신의 비밀키로 복호화한 평문을 확인, A의 공개키로 응답을 암호화하여 A에개 보냄
3. A는 자신의 비밀키로 암호화된 응답문을 복호화함

대칭키의 단점을 완벽하게 해결했지만, 암호화 복호화가 매우 복잡함

(암호화하는 키가 복호화하는 키가 서로 다르기 때문)

대칭키와 공개키 암호화 방식을 적절히 혼합해보면?

SSL 탄생의 시초가 됨

1. A가 B의 공개키로 암호화 통신에 사용할 대칭키를 암호화하고 B에게 보냄
2. B는 암호문을 받고, 자신의 비밀키로 복호화함
3. B는 A로부터 얻은 대칭키로 A에게 보낼 평문을 암호화하여 A에게 보냄
4. A는 자신의 대칭키로 암호문을 복호화함
5. 앞으로 이 대칭키로 암호화를 통신함

즉, 대칭키를 주고받을 때만 공개키 암호화 방식을 사용하고 이후에는 계속 대칭키 암호화 방식으로 통신하는 것!

 

 

+

 

TLS/SSL HandShake

 

HTTPS에서 클라이언트와 서버간 통신 전
SSL 인증서로 신뢰성 여부를 판단하기 위해 연결하는 방식

 

 

 

진행 순서

1. 클라이언트는 서버에게 client hello 메시지를 담아 서버로 보낸다. 이때 암호화된 정보를 함께 담는데, 버전, 암호 알고리즘, 압축 방식 등을 담는다.
2. 서버는 클라이언트가 보낸 암호 알고리즘과 압축 방식을 받고, 세션 ID와 CA 공개 인증서를 server hello 메시지와 함께 담아 응답한다. 이 CA 인증서에는 앞으로 통신 이후 사용할 대칭키가 생성되기 전, 클라이언트에서 handshake 과정 속 암호화에 사용할 공개키를 담고 있다.
3. 클라이언트 측은 서버에서 보낸 CA 인증서에 대해 유효한 지 CA 목록에서 확인하는 과정을 진행한다.
4. CA 인증서에 대한 신뢰성이 확보되었다면, 클라이언트는 난수 바이트를 생성하여 서버의 공개키로 암호화한다. 이 난수 바이트는 대칭키를 정하는데 사용이 되고, 앞으로 서로 메시지를 통신할 때 암호화하는데 사용된다.
5. 만약 2번 단계에서 서버가 클라이언트 인증서를 함께 요구했다면, 클라이언트의 인증서와 클라이언트의 개인키로 암호화된 임의의 바이트 문자열을 함께 보내준다.
6. 서버는 클라이언트의 인증서를 확인 후, 난수 바이트를 자신의 개인키로 복호화 후 대칭 마스터 키 생성에 활용한다.
7. 클라이언트는 handshake 과정이 완료되었다는 finished 메시지를 서버에 보내면서, 지금까지 보낸 교환 내역들을 해싱 후 그 값을 대칭키로 암호화하여 같이 담아 보내준다.
8. 서버도 동일하게 교환 내용들을 해싱한 뒤 클라이언트에서 보내준 값과 일치하는 지 확인한다. 일치하면 서버도 마찬가지로 finished 메시지를 이번에 만든 대칭키로 암호화하여 보낸다.
9. 클라이언트는 해당 메시지를 대칭키로 복호화하여 서로 통신이 가능한 신뢰받은 사용자란 걸 인지하고, 앞으로 클라이언트와 서버는 해당 대칭키로 데이터를 주고받을 수 있게 된다.

[참고사항]

HTTP, 링크 / TLS, 링크