[면접준비] HTTP, HTTPS, SSL

1. HTTP StatusCode

1xx : 조건부 응답

2xx : 클라이언트 요청을 정상적으로 처리하고, 클라이언트에게 전달한 경우 (예 : 200 OK)

3xx : 클라이언트의 요청을 처리한 후, 추가적인 동작을 수행해야 하는 경우

301 (영구이동) : 해당 URL이 영구적으로 새로운 URL로 변경되었음을 의미 

검색엔진 크롤러는 301 요청을 만나면 컨텐트가 완전히 새로운 URL로 영원히 이동했다고 판단 페이지랭킹이나 링크에 대한 점수를 새로운 URL에 전달

302 (임시이동) : 요청한 리소스가 임시적으로 새로운 URL로 이동했음(Temporarily Moved)을 의미 

검색엔진은 페이지랭킹이나 링크에 대한 점수를 새로운 URL로 옮기지 않으며 기존 URL을 그대로 유지 즉, 검색엔진이 기존 URL이 보유한 페이지랭킹 점수는 그대로 유지하도록 하면서 컨텐트만 새로운 URL에서 조회하도록 할때 사용

4xx : 클라이언트 요청의 오류

401 : 클라이언트의 요청에 대해 인증이 필요할 경우 발생하는 오류

인증 : 클라이언트가 자신이 주장하는 클라이언트가 동일한 클라이언트인지 확인하는 과정 (예 : 본인이 작성하지 않는 글을 수정하려는 경우 발생하는 오류)

403 : 클라이언트가 인가되지 않는 요청을 할 때 발생하는 오류

인가 : 클라이언트가 수행하려는 작업이 권한이 있는지, 허락된 작업인지 확인하는 과정 (예 : 로그인하지 않는 사람이 글을 작성하려 했을 경우 발생하는 오류)

5xx : 서버에서 클라이언트 요청을 처리하는 과정에서의 오류

2. TCP 연결 - 3 Hand Shake

(1) Process A 에서 Process B 로 연결요청 (SYN) 전송

(2) Process B 에서는 연결 요청에 대한 응답(ACK)과 프로세스 A에 대한 연결요청 (SYN) 전송

(3) Process A 에서 B로 부터 요청을 받은 후, Process B에게 응답(ACK) 전송

3. TCP 연결 해제 - 4 Hand Shake

(1) Process A가 Process B에게 연결해제 요청 (FIN) 전송

(2) Process B는 연결 해제 요청에 대한 응답 (ACK)를 Process A 에게 전송

(3) Process B는 연결을 해제하고, 연결해제 요청 (FIN) 을 Process A 에게 전송

(4) Process A는 해제에 대한 응답 (ACK) 전달 후, TIME WAIT 상태로 변경

    TIME WAIT을 하면 일정 시간이 지났을 때, 자동으로 연결 해제 Process A는 일정 시간이 지나면 연결이 종료되고, Process B는 ACK 수신 후 연결이 종료

 * TIME WAIT 하는 이유?

   Process A가 연결을 종료하고, Process B와 다시 연결을 맺을 때, 처음 연결 종료 ACK 메세지가 늦게 도착했을 경우 해제와 연결에 대한 문제 발생 가능

   Process A의 ACK 메세지를 Process B에게 전송하는 과정에서 손실한 경우 Process A만 연결을 해제하는 상황 발생

4. HTTP 와 HTTPS

HTTP는 Hyper Transfer Protocol의 약자로서, HTML을 전송하기 위한 통신규약 (기본포트 80)

HTTP 는 네트워크, IP, TCP, HTTP 계층으로 구성

HTTPS는 보안이 강화된 HTTP 를 의미. (TLS를 사용해 암호화된 연결을 하는 HTTP) (기본 포트 443)

암호화되지 않는 방식으로 통신을 할 경우, 메세지의 감청으로 인한 보안 문제 발생 가능

HTTPS는 네트워크, IP, TCP, SSL/TLS, HTTPS 계층으로 구성 (HTTPS는 SSL/TLS 계층 위에서 동작하는 프로토콜)

 - TLS는 HTTP 뿐만 아니라, FTP, SMTP와 같은 다른 프로토콜까지 포함 가능 (HTTPS = HTTP + TLS)

 - SSL은 네스케이프에 의해서 발명되었고, 표준화 기구인 IETF의 관리로 변경되면서 TLS라는 이름으로 변경 

 - TLS 1.0은 SSL 3.0을 계승하고 있기 때문에 같은 개념

5. SSL/TLS

인터넷 상에서 데이터를 안전하게 전송하기 위한 인터넷 암호화 통신 프로토콜 의미

데이터를 송신할 때, HTTP는 애플리캐이션 계층(HTTP) 에서 전송 계층(TCP)로 보내지만, HTTPS는 SSL로 전송하고 SSL은 받은 데이터를 암호화하여, 

전송계층(TCP)로 전달해는 방식으로 데이터를 송신한다. 데이터를 수신할 때, HTTP는 전송 계층(TCP)에서 애플리케이션 계층(HTTP)로 보내지만, HTTPS는 

전송계층(TCP)에서 SSL로 보내고, SSL은 복호화하여 애플리케이션 계층(HTTPS)로 전달하여 데이터 수신한다.

송신할 때는 HTTP는 TCP를 SSL로 인식하고, 수신할 때는 TCP가 HTTP를 SSL로 인식하게 함으로써 동작하기 때문에 기존 전달 방식을 그대로 사용 가능

6. SSL 디지털 인증서

클라이언트와 서버간의 통신을 제 3자가 보증하는 전자화된 문서

클라이언트가 서버에 접속을 하면, 서버는 클라이언트에게 인증서를 전달하고, 클라이언트는 인증서가 신뢰할 수 있는 정보인지 검증 후, 다음 절차를 수행

통신 내용이 공격자에게 노출되는 것을 방지 (암호화 사용)

 - 대칭키 방식 : 암호화(암호 생성)와 복호화(암호 해독)를 같은 키를 이용하는 기법. 대칭키의 단점은 키가 노출되면, 복호화가 가능하기 때문에 보안 위험

 - 공개키 방식(비대칭키 방식) : 개인키(복호화)와 공개키(암호화)가 쌍으로 존재

  (1) 개인키는 본인이 가지고 있으며, 공개키는 상대에게 전송 (양쪽 모두 진행)

  (2) 송신자는 데이터를 보낼 경우에는 상대방의 공개키를 이용해서 암호화하여 전송

  (3) 수신자는 데이터를 받을 경우에는 자신의 개인키를 이용해서 복호화

      공개키를 모두 공개했지만, 오직 자신의 개인키로만 복호화가 가능하기 때문에 키 전달 문제 해결 가능 (대칭키 단점 해결)

      키 배송의 문제는 해결했지만, 암호화/복호화의 비용이 높음

 - SSL 방식 : 대칭키 방식을 사용하고, 키를 전달하는 방식을 공개키 방식으로 하는 기법

  (1) A는 B에게 공개키를 전달

  (2) B는 A에게 전달받은 공개키를 이용해서 자신의 대칭키를 암호화 (B가 암호화한 대칭키는 오직 A가 가지고 있는 개인키로만 복호화가 가능하기 때문에 

      해킹의 위험이 없음)

  (3) A도 위와 같은 절차를 반복

  (4) A와 B는 서로의 대칭키를 보유하고 있기 때문에 서로의 대칭키로 암호화하여 전달

      서로의 대칭키로 암호화를 하기 때문에 비용 감소 (공개키 단점 보완)

      공개키 방식을 사용했기 때문에 키 전달의 보안 위험 해결 (대칭키 단점 보완)

      클라이언트는 서버가 신뢰할 수 있는 서버인지 확인 가능

 - 인증기관 (예 : 아마존)

  (1) 사이트는 사이트 정보와 사이트의 공개키를 인증기관에 전달

  (2) 인증기관은 사이트 정보와 사이트의 공개키는 인증기관의 개인키로 암호화한 후, 브라우저에 전달

  (3) 클라이언트는 사이트의 접속을 할 때, 인증기관이 개인키로 암호화한 사이트 정보와 사이트 공개키 수신

  (4) 클라이언트는 인증기관으로부터 받은 인증기관 공개키를 이용해서 사이트가 전달한 것을 복호화 사이트가 전달한 것은 인증기관이 개인키로 암호화했기        

       때문에 클라이언트는 인증기관의 공개키로 복호화 가능

7. SSL/TLS HandShake 과정

참고 : http://blog.daum.net/tlos6733/57

참고 : https://www.tuwlab.com/ece/26967