HTTP(S), 소켓

HTTP란?

 - 웹 브라우저와 웹 서버 간에 데이터를 주고받는데 사용되는 프로토콜이다. 두 프로토콜 모두 웹 페이지의 HTML, CSS, JS 등의 컨텐츠를 전송하는데 사용되지만 보안에 있어서 중요한 차이가 있다.

 

HTTP : HTTP는 클라이언트(보통 웹 브라우저)와 서버 간의 요청-응답 프로토콜이다. 클라이언트는 HTTP 요청을 서버로 보내고, 서버는 요청받은 리소스에 대한 HTTP 응답을 클라이언트로 보낸다. HTTP는 상태를 유지하지 않는(STATELES) 프로토콜로, 각 요청과 응답이 독립적이며 이전 요청과 응답에 대한 정보를 저장하지 않는다. 하지만 HTTP의 가장 큰 문제는 데이터가 암호화되지 않아서 네트워크 상에서 쉽게 읽힐 수 있다는 것이다. 이는 중간자 공격(Man-in-the-Middel Attack)이나 데이터 도난 등의 보안 위협을 초래한다.

 

HTTPS: HTTP에 SSL(Secure Sockets Layer) 또는 그 후속인 TLS(Transport Layer Security)를 추가한 프로토콜이다. 이는 클라이언트와 서버 사이에 전송되는 모든 데이터를 암호화하여 보안을 강화한다. 

HTTPS연결은 SSL/TLS 핸드셰이크로 시작되는데, 이 과정에서 클라이언트와 서버는 암호화 방식을 협상하고, 서버는 자신의 공개키를 포함한 인증서를 클라이언트에게 제공한다. 클라이언트는 이 인증서를 검증하고, 검증이 성공하면 암호화된 연결이 설정되어 HTTP 요청과 응답이 이 연결을 통해 안전하게 전송된다.

 

HTTP(S)는 GET, POST, PUT, DELETE 등의 메소드를 지원한다. 이들 메소드는 클라이언트가 서버에게 어떤 종류의 요청을 보내는지를 명시한다.

HTTP(S)의 응답에는 상태코드가 포함되어 있다. 이 코드는 요청의 성공 여부와 그 이유를 나타낸다. 예를 들어 '200'은 요청이 성공적으로 처리되었음을, '404'는 요청한 리소스를 찾을 수 없음을 나타낸다.

HTTP(S)는 웹의 핵심적인 요소로, 웹 브라우저와 웹 서버 간에 안전하고 효율적인 데이터 전송을 가능하게 한다. 대키

 

TLS(Transport Layer Security)는 네트워크 통신을 보안하기 위해 설계된 암호화 프로토콜이다.

1. 암호화 : TLS는 데이터를 안전하게 전송하기 위해 암호화를 사용한다. 이를 통해 중간자 공격을 방지하고, 데이터의 기밀성을 보장한다.

2. 인증 : TLS는 서버, 클라이언트 또는 양쪽 모두의 신원을 인증할 수 있다. 이를 위해 디지털 인증서를 사용하며, 보통 인증서는 신뢰할 수 있는 CA(Certificate Authority)에 의해 발급된다.

3. 무결성 보장 : TLS는 데이터가 전송 중에 변경되거나 손상되는 것을 방지하기 위해 메시지 인증 코드(Message Authentication Code, MAC)를 사용한다.

4. 키 교환 : TLS는 안전하게 대칭키를 교환하기 위해 비대칭키 암호화를 사용한다. 이를 통해 서버와 클라이언트는 비밀 키를 공유하지 않아도 암호화된 통신을 수행할 수 있다.

 

동작 과정

1. 클라이언트와 서버는 '핸드셰이크' 과정을 통해 암호화 알고리즘을 협상하고, 서버의 신원을 인증한다.

2. 클라이언트와 서버는 비대칭키 암호화를 사용하여 대칭키를 교환한다.

3. 클라이언트와 서버는 이제 교환된 대칭키를 사용하여 데이터를 암호화, 복호화한다.

4. 클라이언트와 서버가 통신을 종료할 때, 핸드셰이크를 통해 협상한 보안 매개변수는 폐기된다.

 

1. 클과 서버는 핸드셰이크 과정을 통해 암호화 알고리즘을 협상하고, 서버의 신원을 인증한다. 이 과정에서 서버는 클에게 자신의 공개키를 전송한다.

2. 클은 이 공개키를 사용하여 임의의 대칭키를 암호화하고, 이를 서버에게 전송한다. 이렇게 하면, 이 대칭키는 서버의 비밀키를 소유하고 있는 사람만이 복호화할 수 있다.

3. 서버는 자신의 비밀키를 사용하여 이 대칭키를 복호화한다. 이제 클과 서버 모두 이 대칭키를 알고 있게 되므로, 이 키를 사용하여 데이터를 암호화, 복호화할 수 있다.

 

EX) 아파트 보안 시스템

1. 방문객이 경비원에게 자신의 신분을 알리고, 아파트에 들어가고자 하는 의도를 표현(핸드셰이크).

이 때, 경비원(서버)는 방문객(클)에게 자신이 실제 경비원임을 증명하는 아파트 공식 ID 카드(공개키)를 보여준다.

2. 방문객이 경비원에게 전달할 특별한 비밀 메시지(대칭키)를 작성하고, 경비원이 보여준 ID 카드(공개키)로 메시지를 암호화한다. 이렇게 암호화된 메시지는 경비원의 개인 비밀번호(비밀키)를 알고 있는 사람만이 해독가능하다.

3. 경비원이 비밀키를 이용해 방문객이 전달한 암호화된 메시지를 해독. 이제 클과 서버 모두 원래의 비밀 메시지를 알게 되었다. 안전하다.

 

** SSL/TLS 과정 : 

1. 클라이언트 헬로 : 클은 서버에게 헬로 메시지를 보내고, 사용할 수 있는 암호화 방법(사이퍼 스위트)와 랜덤하게 생성된 데이터를 전달한다. 또한 세션 ID를 포함하여 이전 세션을 재개할 수 있는 정보를 제공할 수도 있다.

2. 서버 헬로 : 서버는 클의 헬로 메시지를 받고, 사용할 암호화 방법을 선택하고 이를 클라이언트에게 알린다. 또한 랜덤하게 생성된 데이터를 클에게 전달한다.

3. 인증 및 키 교환 : 서버는 인증서를 클에게 제공한다. 인증서에는 서버의 공개 키, 인증서 발급자 정보, 서버의 도메인 이름 등이 포함되어 있다. 클은 이 인증서를 검증하고, 검증이 성공하면, 클은 공개키를 사용하여 세션 키를 암호화하고 서버에게 전송한다. 서버는 자신의 개인키를 사용하여 세션키를 복호화한다.

4. 핸드셰이크 종료 : 이제 클과 서버 모두 암호화된 통신을 시작할 준비가 되었다. 클과 서버는 각각 Finished 메시지를 전송하여 핸드셰이크 과정이 끝났음을 알린다.

 

공개키 암호화 : 공개키로 암호화를 하면 개인키로만 복호화할 수 있다. => 개인키는 나만 가지고 있으므로, 나만 볼 수 있다.

개인키 암호화 : 개인키로 암호화하면 공개키로만 복호화할 수 있다. => 공개키는 모두에게 공개되어 있으므로, 내가 인증한 정보임을 알려 신뢰성을 보장할 수 있다.

 

HTTPS 연결 과정 성립 흐름

1. 클(브라우저)가 서버로 최초 연결 시도를 함 - 웹 브라우저에서 HTTPS로 시작하는 웹 페이지를 열려고 하면, 브라우저는 해당 웹 서버에 연결을 요청한다. 마치 전화를 걸어서 통화를 요청하는 것과 비슷

 

2. 서버는 공개키(엄밀히는 인증서)를 브라우저에게 넘겨줌 - 웹 서버는 자신의 공개키가 담긴 인증서를 브라우저에게 전송한다. 이 인증서는 여러 정보를 담고 있는데, 그 중에서도 가장 중요한 것이 서버의 공개키이다. 이 공개키는 암호화된 정보를 복호화하거나, 반대로 정보를 암호화하는데 사용된다.

 

3. 브라우저는 인증서의 유효성을 검사하고 세션키를 발급함 - 브라우저는 받은 인증서가 신뢰할 수 있는 인증기관에 의해 발행되었는지 확인한다. 이 과정을 통해 서버가 실제로 해당 웹사이트를 운영하는 사람이라는 것을 브라우저가 알 수 있다. 이것이 확인되면 브라우저는 이번 세션(현재의 연결)에서 사용할 세션키를 생성한다.

 

4. 브라우저는 세션키를 보관하며 추가로 서버의 공개키로 세션키를 암호화하여 서버로 전송함 - 브라우저는 앞서 생성한 세션키를 서버의 공개키로 암호화한다. 이렇게 암호화된 세션키를 서버에게 전송한다. 이 과정은 마치 비밀 메시지를 전달하는 과정과 비슷하다. 브라우저는 서버의 공개키로 메시지(세션키)를 암호화하므로, 이 메시지는 서버만이 복호화할 수 있다.

 

5. 서버는 개인키로 암호화된 세션키를 복호화하여 세션키를 얻음 - 서버는 자신의 개인키를 사용하여 암호화된 세션키를 복호화한다. 이렇게 해서 서버도 세션키를 얻게 된다. 이제 클과 서버는 동일한 세션키를 갖게 되었다.

 

6. 클과 서버는 동일한 세션키를 공유하므로 데이터를 전달할 때 세션키로 암호화/복호화를 진행함. - 이제 클과 서버는 서로 암호화된 데이터를 주고 받을 수 있게 되었다. 클은 데이터를 세션키로 암호화하여 서버에게 전송하고, 서버는 세션키로 암호화된 데이터를 복호화하여 읽을 수 있다. 반대로 서버가 데이터를 세션키로 암호화하여 클에게 전송하면, 클은 세션키로 암호화된 데이터를 복호화하여 읽을 수 있다.

 

 

 

 

HTTPS의 발급 과정

서버가 비대칭키를 발급받는 과정

1. A기업은 HTTP 기반의 애플리케이션에 HTTPS를 적용하기 위해 공개키/개인키를 발급함 - A기업은 먼저 공개키와 개인키를 발급한다. 이 두 키는 서로 수학적으로 연관되어 있어, 공개키로 암호화한 내용은 개인키로만 복호화할 수 있고, 반대로 개인키로 암호화한 내용은 공개키로만 복호화할 수 있다.

 

2. CA 기업에게 돈을 지불하고, 공개키를 저장하는 인증서의 발급을 요청함 - 공개키는 누구에게나 공개될 수 있으므로, 이를 안전하게 저장하고 배포할 수 있는 인증서가 필요하다. A기업은 이를 위해 CA라는 신뢰할 수 있는 제 3자 기관에게 인증서 발급을 요청한다.

 

3. CA 기업은 CA 기업의 이름, 서버의 공개키, 서버의 정보 등을 기반으로 인증서를 생성하고, CA 기업의 개인키로 암호화하여 A기업에게 이를 제공한다. - CA 기업은 A기업의 공개키, A기업의 신원 정보, 그리고 CA 기업의 디지털 서명 등을 포함하는 인증서를 생성한다. 디지털 서명은 CA 기업의 개인키로 생성되며, 이를 통해 인증서의 진위를 확인할 수 있다.

 

4. A기업은 클에게 암호화된 인증서를 제공함 - A기업의 웹 서버는 클이 연결을 요청할 때 CA 기업에게서 받은 인증서를 클에게 전송한다.

 

5. 브라우저는 CA 기업의 공개키를 미리 다운받아 갖고있어, 암호화된 인증서를 복호화함 - 클의 브라우저는 인증서를 받으면 CA 기업의 공개키로 인증서를 복호화한다. 이 과정을 통해 인증서가 CA 기업에 의해 발급되었음을 확인하고, A기업의 공개키를 얻을 수 있다.

 

6. 암호화된 인증서를 복호화하여 얻은 A기업의 공개키로 세션키를 공유함 - 브라우저는 이제 A기업의 공개키를 가지고 있으므로, 이를 통해 A기업과 안전하게 통신할 수 있는 세션키를 생성하고 공유한다. 이 세션키는 이후의 통신에서 데이터를 암호화하고 복호화하는데 사용된다.

 

 

 

HTTP 상태 401(Unauthorized) vs 403(Forbidden)

401 - 클라이언트가 인증되지 않았거나, 유효한 인증 정보가 부족하여 요청이 거부되었음을 의미하는 상태값이다. 즉, 클라이언트가 인증되지 않았기 때문에 요청을 정상적으로 처리할 수 없다고 알려주는 것이다.

403 - 서버가 해당 요청을 이해했지만, 권한이 없어 요청이 거부되었음을 의미하는 상태다. 즉, 클라이언트가 해당 요청에 대한 권한이 없다고 알려주는 것이다.

 

403은 '해당 요청에 대한 자원이 존재함'을 내포한다. 즉, '리소스의 존재 여부'를 알 수 있다. 이러한 부분은 취약점을 찾아서 파고드려는 공격자에게 힌트를 주는 셈이 될 수 있다. 따라서 보안 정책에 따라서 권한이 없음을 알리는 것이 아니라, 자원의 존재 자체를 숨기고 싶은 경우에는 404(Not Fount)를 사용하는 것이 적합할 수도 있다.

 

 

 

GET vs POST - 클라이언트가 서버로 요청을 보내는 방법

1. GET : 어떠한 정보를 가져와서 조회하기 위해서 사용되는 방식

 특징 

 - URL에 변수(데이터)를 포함시켜 요청한다.

 - 데이터를 Header(헤더)에 포함하여 전송한다.

 - URL에 데이터가 노출되어 보안에 취약하다.

 - 캐싱할 수 있다.

 

2. POST : 데이터를 서버로 제출하여 추가 또는 수정하기 위해서 사용하는 방식

 특징

 - URL에 변수(데이터)를 노출하지 않고 요청한다.

 - 데이터를 Body(바디)에 포함시킨다.

 - URL에 데이터가 노출되지 않아서 기본 보안은 되어 있다.

 - 캐싱할 수 없다.

 

 

 

 

 

 

HTTP vs REST

공통점 : 모두 STATELESS하다.

HTTP는 STATELESS한 성격을 가진 '프로토콜'

REST는 STATELESS한 성격을 가진 '설계 구조'

 

Stateless vs Connectionless

Stateless(무상태성) : 필요한 상태에 대한 정보를 클라이언트가 가지고 오기 때문에 클라이언트의 요청에 어느 서버가 응답해도 상관 없음. 따라서 클라이언트의 요청이 대폭 증가하면 서버를 증설해 해결할 수 있음.

Connectionless(비연결성) : 클라이언트가 서버에 요청을 하고 응답을 받으면 바로 TCP/IP 연결을 끊어 연결을 유지하지 않음으로써 서버의 자원을 효율적으로 관리하고  수많은 클라이언트의 요청에 대응할 수 있게 함.

=> 즉 무상태성은 클라이언트와 서버 간에 상태 정보를 들고 있지 않아 클라이언트가 상태 정보를 일일히 HTTP에 실어 요청해야 하는 것을 말하고,

비연결성은 서버 간에 네트워크 연결이 끊어져 단절된다고 이해하면 된다.

 

소켓

구글 검색과 유튜브 시청을 동시에 하면 프로토콜, 포트 뭐쓰는지?

 두 서비스 모두 HTTPS 프로토콜 사용. 포트는 기본적으로 443번 포트를 사용.

그런데 어떻게 동일한 포트를 사용하면서 서로 다른 서비스를 이용할 수 있나? 이는 TCP/IP의 '소켓' 개념 때문이다.

소켓은 IP 주소, 포트 번호, 그리고 프로토콜로 구성되며, 이 세 가지 요소가 모두 동일해야지만 동일한 소켓으로 판단된다.

구글과 유튜브는 같은 프로토콜(HTTPS)와 포트(443)을 사용하지만, 각각의 서비스는 서로 다른 IP 주소를 갖는다. 그래서 이 둘은 서로 다른 소켓을 통해 통신하게 되며, 이를 통해 동시에 두 서비스를 이용할 수 있게 된다.

 

 

 

 

출처 : https://mangkyu.tistory.com/