HTTP 설명 (GET vs POST) (HTTP vs HTTPS)

HTTP (Hypertext Tranfer Protocol)

클라이언트와 서버와 통신을 가능케 하는 프로토콜이다.

• 브라우저로 인터넷에 접속하는데 사용된다.
• TCP/IP 위에서 동작한다.
• 클라이언트가 서버로 요청하는 것이 통신의 시작이다.
• 이 요청의 목적을 Method로 표시한다.
• Method 중 대표적인 GET, POST를 살펴볼 것이다.

특징

단방향성	클라이언트가 서버로 요청을 보내고 이에 대한 응답을 받는 단방향적 통신이다.
비연결성	연결이 계속 유지되지 않고 요청에 대한 응답이 끝나면 연결을 끊는다.
무상태성	클라이언트가 서버와 연결된 상태가 아니기 때문에 기본적인 상태를 가지지 않는다. 이를 보안하기 위해 쿠키, 세션, 토큰 등을 사용한다.

응답 코드

2xx	성공 요청이 정상적으로 이주어졌다.
3xx	리다이렉션, 요청을 완료하기 위해 다른 주소로 이동해야 한다.
4xx	클라이언트 오류. 올바르지 않은 요청
5xx	서버 오류. 올바른 요청에 대해 서버의 문제로 응답 불가능

 

GET vs POST

클라이언트가 HTTP 프로토콜로 서버에 무언가 요청할 때 사용되는 데이터 전달 방식이다.

GET

• 서버의 데이터를 가져올 때 사용한다.
• HTTP Request Message의 헤더 부분의 URL에 요청하는 데이터를 담아서 전송한다.
• URL 에서 ?뒤에 데이터가 붙어서 요청하는 것이다.
• 이 방식은 URL이라는 공간에 담겨가기 때문에 보낼 수 있는 데이터 크기가 제한적이다.
• 데이터가 그대로 노출되므로 보안에 취약하다.
• 브라우저에서 캐싱할 수 있기 때문에 보안에 취약하지만 편하기도 하다.

POST

• 서버 쪽에 어떤 작업을 명령할 때 사용된다. (데이터 추가, 삭제, 수정)
• HTTP Request Message의 body 부분에 데이터가 담겨서 전송된다.
• GET보다 보낼 수 있는 데이터의 크기가 더 크고 보안이 좀 더 낫다.

URL

• Uniform resource locator : 자원의 위치
• 쉽게 말하면 인터넷 주소이고 2가지로 표시할 수 있다.
  
  • 도메인 name
  • ip 주소
• 앞에 프로토콜(http://)이 붙는다.

 

HTTP vs HTTPS

HTTP의 문제점

1. 평문 통신이기 때문에 도청이 가능하다.
2. 통신 상대를 확인하지 않기 때문에 위장이 가능하다.
3. 완전성을 증명할 수 없기 때문에 변조가 가능하다.

 

HTTPS의 S는 Secure로 HTTP의 보안을 강화한 프로토콜이다.

• 어떤 웹 서버에 보내는 정보를 다른 사람이 보지 못하도록 암호화한다.
• 접속하려는 사이트가 신뢰할 수 있는 사이트인지 확인하여 수상한 사이트를 걸러낸다.

대칭키

• 하나의 키로 암호화와 복호화를 하여 데이터를 주고 받는다.
• 이 키를 공유하는 과정이 보안에 취약하다.

비대칭키

• 두 개의 키로 서로가 암호화한 것을 복호화할 수 있다.
• 웹 서버는 하나의 키(공개키)를 모두에게 공개한다.
• 클라이언트가 아이디와 비밀번호를 공개키로 암호화하면 비대칭키를 갖는 웹 서버만 그 정보를 이해할 수 있다.
• CA(Certificate Authority)에서 공개키가 정품인지 확인한다.
• 웹 서버가 암호화한 데이터를 공개키로 복호화할 수 있다면 신뢰할 수 있는 사이트이다.

통신 순서

1. 신뢰할 수 있는 사이트인지 알아보기 위해 클라이언트는 랜덤 데이터를 생성해서 서버에 보낸다.
2. 데이터를 받은 서버 측은 다른 무작위 데이터와 해당 서버의 인증서를 실어보낸다.
3. 인증서가 진짜인지 브라우저에 내장된 CA들의 정보를 통해 확인한다.
   
   • CA의 인증을 받은 인증서들은 해당 CA의 개인키로 암호화가 되어있다.
   • 진짜 인증서라면 CA의 공개키로 복호화할 수 있다.
4. 클라이언트는 앞의 무작위 데이터를 혼합해서 임시 키를 만든다.
5. 임시 키를 서버의 공개키로 암호화해서 서버로 보낸다.
6. 서버와 클라이언트는 일련의 과정으로 임시 키를 대칭키로 만든다.
7. 이 대칭키로 서버와 클라이언트가 통신을 한다.

공개키를 얻는 과정

1. 서비스를 제공하는 기업 A가 공개키와 개인키를 만든다.
2. 신뢰할 수 있는 CA 기업을 선택하고 공개키를 관리해주기 위한 계약을 한다.
3. 계약이 성사되면 CA 기업은 자신의 개인키로 인증서를 만든다.
   • 인증서 : CA 기업 정보 + A 서버의 공개키 + 공개키 암호화 방법 등을 CA 기업의 개인키로 암호화한 인증서
4. 클라이언트가 공개키가 없는 상태에서 A의 서버로 접속하기 위해서 HTTPS 가 아닌 요청을 한다.
5. 서버는 인증서를 클라이언트에게 보낸다.
6. 클라이언트의 브라우저는 CA 기업의 공개키를 알고 있으므로 복호화해서 공개키를 얻는다.

여기서 CA의 공개키로 복호화가 가능하다는 것은 CA의 개인키로 암호화한 인증서라는 것을 알 수 있다.