[CS] HTTP, HTTPS 그리고 SSL

HTTP (Hyper-Text Transfer Protocol)

• HTTP는 클라이언트와 서버가 데이터를 주고받기 위한 프로토콜입니다.
• 인터넷에서 하이퍼텍스트를 교환하기 위한 통신 규약으로, 80번 포트를 사용하고 있습니다.
• 애플리케이션 레벨의 프로토콜로 TCP/IP 위에서 작동합니다.
• 비연결 지향 
  • 브라우저를 통해 사용자의 요청으로 서버와 접속하여 요청에 대한 응답의 데이터를 전송한 후 연결을 종료합니다. 
  • 과정이 간단하기 때문에 자원이 적게 든다는 장점이 있습니다.
  • 하지만 여러 사용자가 요청할 시 각각의 사용자 요청을 구분할 수 없어서 제대로 된 응답 데이터를 전송할 수 없다는 단점이 있습니다. 
  • 해결 방법으로는 쿠키, 세션, 히든 폼 필드 등이 있습니다. 
• 단방향성 
  • 사용자의 요청 한 개에 대해 한 개의 응답을 하는 방식이기 때문에 서버가 먼저 응답하지 않습니다.

 

HTTP의 동작 과정

HTTP는 클라이언트가 브라우저를 통해 요청(Request)를 보내면, 서버는 해당 요청(Request)를 받아 처리를 하여 클라이언트에게 응답(Response)을 하는 형태로 이루어집니다.

 

HTTP Method

메서드	설명
GET	URI가 가진 정보를 검색하기 위해 요청하는 메소드
HEAD	GET메소드와 방식은 동일하지만, 응답에 BODY가 없고 응답 코드와 HEAD만 응답하는데 사용되는 메소드
POST	요청된 자원을 생성하기 위한 메소드
PUT	요청된 자원을 수정할때 사용하고, PATHCH와는 다르게 자원 전체를 갱신하는데 사용되는 메소드
PATCH	PUT메소드와 유사하게 요청된 자원을 수정할때 사용되지만, 자원의 일부를 수정하는 의미로 사용되는 메소드
DELETE	요청된 자원을 삭제하기 위한 메소드
CONNECT	동적으로 터널 모드를 교환하고 프락시 기능을 요청할때 사용하는 메소드
TRACE	원격 서버에 루프백 메세지를 호출하기 위해 테스트용도로 사용하는 메소드
OPTIONS	웹 서버에서 지원하는 메소드의 종류들을 확인할 경우 사용하는 메소드

 

HTTP Status Code

정보전송 임시응답 (1xx)

• 서버가 요청을 클라이언트에서 성공적으로 수신을 했고 서버에서 처리중인 정보를 보냅니다. 

  Status Code	설명
  100	Continue
  101	Swiching protocols

성공 (2xx)

• 서버가 요청을 성공적으로 받았음을 알려줍니다.

  Status Code	설명
  200	Ok!
  201	Created
  202	Accepted
  203	Non-authoritative Information
  204	No Cotent

리다이렉션 (3xx)

• 캐싱된 파일을 새로고침하여 확인하면 3xx대 코드을 받을 수 있습니다.

  Status Code	설명
  301	Moved permanently
  302	Not temporarily
  303	Not modified

클라이언트 요청 오류 (4xx)

• 클라이언트에서 서버에 잘못된 요청을 보내 서버가 요청을 해결할 수 없을 때 발생하는 코드이며, 클라이언트 측에서 발생하는 코드입니다.

  Status Code	설명
  400	Bad Request
  401	Unauthorized
  402	Payment required
  403	Forbidden
  404	Not found
  405	Method not allowed
  407	Proxy authentication required
  408	Request timeout
  410	Gone
  412	Precondition failed
  414	Request-URI too long

서버에러 (5xx)

• 클라이언트의 요청을 받고 서버에서 처리하지 못할때 발생하는 코드이며, 서버 측에서 발생하는 코드입니다.

  Status Code	설명
  500	Internal server error
  501	Not implemented
  503	Service unnailable
  504	Gateway timeout
  505	HTTP version not supported

 

HTTP의 문제점

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

이러한 문제점을 해결하기 위해 HTTPS가 등장하게 되었습니다.

 

HTTPS (Hyper-Text Transfer Protocol Secure)

• HTTPS는 HTTP 통신하는 소켓 부분을 인터넷 상에서 정보를 암호화하는 SSL(Secure Socket Layer)라는 프로토콜로 대체한 것입니다.
• HTTP와 다르게 443번 포트를 사용하며, 네트워크 상에서 중간에 제3자가 정보를 볼 수 없도록 암호화를 지원하고 있습니다.
• HTTP는 직접 TCP와 통신했지만, HTTPS에서는 HTTP가 SSL과 통신하고 SSL이 TCP와 통신합니다.
• 즉, 하나의 레이어를 더 둔 것이라고 생각하면 됩니다.
• HTTPS의 SSL에서는 대칭키 암호화 방식과 공개키 암호화 방식을 모두 사용합니다.

 

HTTPS의 동작 과정

HTTPS는 대칭키 암호화와 공개키 암호화를 모두 사용하여 빠른 연산 속도와 안정성을 모두 얻고 있습니다.

 

HTTPS 연결 과정에서는 먼저 서버와 클라이언트 간에 세션키를 공유합니다.

여기서 세션키는 주고 받는 데이터를 암호화하기 위해 사용되는 대칭키입니다.

이 세션키를 클라이언트와 서버가 공유하는 과정에서 공개키가 사용됩니다.

 

즉, 처음 연결을 성립하여 안전하게 세션키를 공유하는 과정에서 공개키가 사용되는 것이고, 이후에 데이터를 교환하는 과정에서 빠른 연산 속도를 위해 대칭키가 사용됩니다.

 

SSL (Secure Sockets Layer)

SSL 프로토콜은 Netscape 사에서 웹 서버와 브라우저 사이의 보안을 위해 만들어졌습니다.

CA(Certificate Authority)라 불리는 인증된 기관으로부터 클라이언트와 서버의 인증을 하는데 사용할 인증서를 발급받습니다.

1. 서버를 운영하는 기업은 HTTPS 적용을 위해 공개키와 개인키를 만듭니다.
2. 신뢰할 수 있는 CA 기업을 선택하고 인증서 생성을 요청합니다.
3. CA 기업은 서버의 공개키, 암호화 방법 등의 정보를 담은 인증서를 만들고 해당 CA 기업의 개인키로 암호화하여 서버에 제공합니다.
4. 클라이언트가 SSL로 암호화된 페이지(https://)를 요청 시, 서버는 클라이언트에게 암호화된 인증서를 제공합니다.

 

인증서에 포함되는 내용

• 서버 측 공개키
• 공개키 암호화 방법
• 인증서를 사용한 웹 서버의 URL
• 인증서를 발행한 기관 이름

 

클라이언트와 서버의 통신 흐름 과정

1. 클라이언트가 SSL로 암호화된 페이지를 요청합니다.
2. 서버는 클라이언트에게 인증서를 전송합니다.
3. 클라이언트는 인증서가 신용이 있는 CA로부터 서명된 것인지 판단합니다. 브라우저는 CA 리스트와 해당 CA의 공개키를 가지고 있습니다. 공개키를 활용하여 인증서가 복호화가 가능하다면, 접속한 사이트가 CA에 의해 검토되었다는 것을 의미하기 때문에 서버가 신용이 있다고 판단합니다. 공개키가 데이터를 제공한 사람의 신원을 보장해주는 것으로 이러한 것을 전자 서명이라고 합니다.
4. 클라이언트는 CA의 공개키를 이용해 인증서를 복호화하고 서버의 공개키를 획득합니다.
5. 클라이언트는 서버의 공개키를 사용해 랜덤 대칭 암호화키, 데이터 등을 암호화하여 서버로 전송합니다.
6. 서버는 자신의 개인키를 이용해 복호화하고 랜덤 대칭 암호화키, 데이터 등을 획득합니다.
7. 서버는 랜덤 대칭 암호화키로 클라이언트 요청에 대한 응답을 암호화하여 전송합니다.
8. 클라이언트는 랜덤 대칭 암호화키를 이용해 복호화하고 데이터를 이용합니다.