HTTP & HTTPS

HTTP(HyperText Transfer Protocol)

• 웹 상에서 클라이언트와 서버 사이에 이루어지는 요청/응답 프로토콜.

• 주로 HTML 문서를 주고받을 때 쓰이며 보통 80번 포트를 사용한다.

• HTTP는 HTML페이지 즉 텍스트를 주고받기 때문에 보안에 취약하다.

• Method, Path, Version, Headers, Body 등으로 구성

• HTTP의 응답코드

  1. 1XX : 정보교환
  2. 2XX : Success (200번대까지의 응답코드는 성공!!)
  3. 3XX : Redirection (자료의 위치가 바뀌었음)
  4. 4XX : Client Error (클라이언트 측의 오류)
     1) 400 : 요청상의 오류가 있어서 서버가 요청사항을 이해하지 못함
     2) 401 : 권한없음
     3) 404 : 문서를 찾을 수 없음
     4) 405 : 메서드 허용 오류
  5. 서버 측의 오류로 올바른 요청을 처리할 수 없음
     1) 501 : 필요한 기능이 서버에 설치되지 않았음
     2) 502 : 게이트웨이 상태 나쁨
     3) 505 : 해당 HTTP 버전을 지원하지 않음
     

HTTPS(HyperText Transfer Protocol Secure)

• 웹통신 프로토콜인 HTTP의 보안이 강화된 버전

• 소켓 통센에서 일반 텍스트를 이용하는 대신에 SSL이나 TLS 프로토콜을 통해 세션 데이터를 암호화한다

• 기본 포트는 주로 443을 사용한다

  TLS(Transport Layer Sequrity)
  	컴퓨터 네트워크에 통신보안을 제공하기 위해 설계된 암호규약.
      	Application계층에서 만들어진 메세지가 Transport 계층으로 가기 전 SSL을 통해 암호화 된다
  	통신과정에서 전송계층간 보안과 데이터 무결성을 확보해준다.
      	공개키 암호화를 사용하여 텍스트를 암호화한다.
          스니핑 공격에는 뛰어난 보안성을 보이지만 개인정보유출, DDoS, 악성코드 공격에 취약하다.
  
  SSL(Secure Sockets Layer) : TLS의 과거 명칭

HTTPS 통신 흐름

• 공개키 암호화 방식을 사용하여 보안성을 높인다.
  알아둬야할 것 : 공개키A, 개인키 B가 있다고 가정하면 A로 암호화 한 것은 B로만 풀 수 있고, B로 암호화 한 것은 A로만 풀 수 있다.

1. 기업은 HTTPS를 적용하기 위해 공개키와 개인키를 만든다.
2. 공개키를 관리하기 위해 CA기업을 선정한 후 인증서 발급을 요청함(CA(Certificate Authority) : 인증서를 발급하는 기관으로 신뢰할 수 있는 기관)
3. CA기업은 CA기업의 개인키로 암호화 한 인증서를 생성하여 A기업에 제공
4. A기업은 클라이언트에게 암호화된 인증서를 제공함
5. 브라우저는 CA기업의 공개키를 알고 있기 때문에 암호화된 인증서를 복호화함
6. 복호화한 인증서를 통해 A의 공개키를 클라이언트가 알게 됨
7. A의 공개키를 이용하여 암호화하여 A와 통신
8. 보통 클라이언트가 대칭키를 A의 공개키로 암호화하여 A에 전달. 이후 대칭키를 사용하여 통신

• CA가 해당 사이트가 진짜인지를 대신 증명해줌.(A가 신뢰성 있는 사이트인지를 확인할 수 있음)
• A의 공개키를 사용하여 복호화 함으로써 A의 서버에서 왔는지를 증명할 수 있음

HTTP Vs HTTPS

• HTTP는 보안에 취약하고 HTTPS는 보안성이 좋음
• 암호화 과정이 있기 때문에 HTTPS가 HTTP보다 속도가 느림(최근에는 거의 차이를 느끼지 못함)
• HTTP와 달리 HTTPS는 CA를 통해 인증서를 발급하고 유지하기 위해 추가비용이 발생한다.
• 개인정보와 같은 민감한 데이터를 주고 받아야 한다면 => HTTPS
• 단순한 정보 조회 등만을 처리한다면 => HTTP