HTTP(Hypertext Transfer Protocol)는 클라이언트와 서버 간 통신을 위한 데이터를 주고 받는 통신 규칙 또는 프로토콜이다.풀어서 설명하면 하이퍼텍스트(HyperText)를 전송(Transfer)하기 위해 사용되는 통신 규약(Protocol)이다. HTTP는 웹 브라우저와 웹 서버의 소통을 위해 디자인되었으며, 전통적인 클라이언트-서버 아키텍처 모델에서 클라이언트가 HTTP 메시지 양식에 맞춰 요청을 보내면, 이에 서버는 HTTP 메시지 양식에 맞춰 응답을 한다.
IP (인터넷 프로토콜)의 역할 *지정한 IP주소에 데이터 전달 *패킷(Packet)_규칙이라는 통신 단위로 데이터 전달 IP패킷에는 출발지IP, 목적지IP를 담아 간다는걸 우선 생각(다른것도 있음) TCP/UDP TCP : 전송 제어 프로토콜 UDP : 사용자 데이터그램 프로토콜 IP만으로 해결되지 않았던걸 TCP로 보충을해서 해결하고 자함 PORT
• 0 ~ 65535 할당 가능 • 0 ~ 1023: 잘 알려진 포트, 사용하지 않는 것이 좋음 • FTP - 20, 21 • TELNET - 23 • HTTP - 80 • HTTPS - 443
클라이언트가 서버한테 요청을 하는데 IP + TCP/UDP의 전송 메세지가 담긴 패킷에 HTTP요청 메세지를 담아서 보낸다.
▼
그럼 IP/TCP에 담긴 정보로 서버를 찾아가서 HTTP에 담긴 메세지로 그에 맞는 웹 페이지를 띄우게 된다.
HTTP 서버는 기본 포트인 80번 포트에서 서비스 대기 중이며, 클라이언트(웹 브라우저)가 TCP 80 포트를 사용해 연결하면 서버는 요청에 응답하면서 자료를 전송한다. HTTP는 정보를 텍스트로 주고 받기 때문에 네트워크에서 전송 신호를 인터셉트 하는 경우 원하지 않는 데이터 유출이 발생할 수 있다.
HTTPS
보안 취약점을 해결하기 위해 인터넷 컨텐츠를 전달하는 TCP 프로토콜의 일종인 HTTP에S(Secure Socket) 기능을 추가한 것 HTTPS이다.
안전한 데이터의 전달이 브라우저와 웹 서버 사이의 전달 구간에서 이루어지기 때문에, 보안 채널(secure channel), 전송 보안(secure transit)이라고 부르기도 한다.
HTTPS는 기본 골격이나 사용 목적 등은 HTTP와 거의 동일하지만, 데이터를 주고 받는 과정에 ‘보안’ 요소가 추가되었다는 것이 가장 큰 차이점이다. HTTPS를 사용하면 서버와 클라이언트 사이의 모든 통신 내용이 암호화된다.
HTTP 메시지는 일반 텍스트이므로, 권한이 없는 당사자가 인터넷을 통해 쉽게 액세스하고 읽을 수 있다. 반면, HTTPS는 모든 데이터를 암호화된 형태로 전송한다. 사용자가 민감한 데이터를 제출할 때 제3자가 네트워크를 통해 해당 데이터를 가로챌 수 없음을 확신할 수 있다. 신용카드 세부 정보 또는 고객 개인 정보와 같은 잠재적으로 민감한 정보를 보호하려면 HTTPS를 선택하는 것이 좋다.
HTTPS는 SSL이나 TLS 프로토콜을 통해 세션 데이터를 암호화하며, 기본 TCP/IP Port는 443이고, SSL 프로토콜 위에서 HTTPS 프로토콜이 동작한다. HTTPS를 사용하는 웹페이지의 URI는 'http://'대신 'https://'로 시작한다.
TLS & SSL HTTPS의 원천 기술로는 SSL(Secure Socket Layer)과 TLS(Transport Layer Security) 전송 기술이 있다. 안전한 계층을 웹 통신에 추가하는 방식이다. 이 기술을 수행하기 위해 웹 서버에 설치하는 것이 SSL, TLS 인증서이다. TLS는 SSL의 개선 버전으로, 최신 인증서는 대부분 TLS를 사용하지만 편의적으로 SSL 인증서라고 한다. 웹 브라우저는 공신력있는 인증서의 정보를 브라우저 내부에 보관하고 있으며, 접속하는 웹 사이트에 믿을만한 인증서가 설치되어 있는지 확인한다.
HTTPS 암호화 방식
대칭키 암호화 방식(비밀키 방식)_Symmetric Key
동일한 키로 암호화, 복호화가 가능하다.
동일한 키를 주고받기 때문에, 매우 빠르다.(공개키보다 빠르게 통신 가능)
대칭키는 매번 랜덤으로 생성되어 누출되어도 다음에 사용할 때는 다른 키가 사용되기 때문에 안전하다.
대칭키 전달과정에서 해킹 위험에 노출, 이를 보완하여 등장한 방식이 비대칭 키 또는 공개 키라고 불리는 시스템이다.
공개키 암호화 방식(비대칭키 방식)_Public Key
비대칭 키에는 2개의 키가 사용되는데 A키와 B키는 한 쌍이지만 서로 다르기 때문에 비대칭키라 부른다.
A키로 암호화를 하면 B키로 복호화를 할 수 있다.
B키로 암호화를 하면 A키로 복호화를 할 수 있다.
둘 중 하나를 비공개키(Private Key) 혹은 개인키라 부르며, 이는 자신만 가지고 있고 공개되지 않는다.
나머지 하나를 공개키(Public Key)라고 부르며 타인에게 제공한다. 공개키는 유출이 되어도 비공개키를 모르면 복호화 할 수 없기 때문에 안전하다.
대칭키는 암호화,복호화에 똑같은 키를 쓰고 비대칭키는 암호화,복호화에 다른 키를 쓰는 것이다.
복호화 또는 디코딩(decoding) 부호화(encoding)된 데이터를 부호(code)화 되기 전 형태로 바꾸어, 사람이 읽을 수 있는 형태로 되돌려놓는 것
https는 대칭키와 공개키(비대칭키) 두 개를 교묘하게 이용해서 쓰고 있다.
handshaking 과정에 비대칭키를 써서 인증서(대칭키)를 보내고 이 인증서에 대칭키를 안전하게 받았다면 연결 이후에는 대칭키를 사용해서 전달하게 된다.
1단계: 클라이언트는 서버에게 정보는 건넨다.
이때 랜덤한 데이터와 현재 지원할 수 있는 암호화 방식을 서버에게 전달한다. 암호화 방식을 전달하는 이유는 같은 대칭키, 공개 키 기법이라도 다양한 암호화 방식이 있으므로 서로 어떤 암호화 방식을 사용할지 협의하는 과정이 필요하기 때문이다.
2단계: 클라이언트의 인사를 받은 서버는 똑같이 클라이언트에게 정보를 건넨다.
이때 서버는 세 가지 내용 을 전달하는데, 앞서 클라이언트가 전달한 내용과 동일한 랜덤 데이터와 지원 가능한 암호화 방식, 인증서를 전달한다. 인증서란 서버가 공식으로 인증된 기관인 CA(Certific ate Authority)에서 발급받은 문서로, 서버가 신뢰할 수 있는지 보장하는 역할을 한다.
3단계: 인증서를 받은 클라이언트는 이 인증서가 제대로 된 문서인지 검증하기 위해, CA가 발급한 인증서 목록 중에서 서버가 전달한 인증서가 있는지 확인한다.
그리고 인증서가 목록에 있다면 한 번 더 확인하기 위해서 CA에서 공유하는 공개키를 가지고 인증서를 복호화한다. 복호화에 성공한다면 이 인증서는 서버가 자신의 비밀키로 암호화를 했다는 것이 검증되니 이 서버를 신뢰할 수 있는 것이다.
4단계: 본격적으로 키를 주고받기 위해 클라이언트는 실제 데이터 통신에서 사용할 대칭키를 임시로 만든다.
이때 앞서 클라이언트와 서버가 서로 주고받은 랜덤한 데이터를 조합해 임시 키(pre master secret)를 생성하는데요. 임시 키는 대칭키이기 때문에 절대 중 간에 제삼자에게 노출되어선 안 되므로 앞서 갖고 있 던 공개키로 암호화해 서버에게 전달한다.
5단계: 키를 받은 서버는 자신이 갖고 있던 비밀키로 암호를 해독해 임시 키를 전달받게 된다.
비로소 클 라이언트와 서버가 같은 키 즉, 동일키를 갖게 된 것
6단계: 클라이언트와 서버의 임시 키는 일련의 과정을 거쳐 세션 키로 바뀌고, 이 세션 키를 이용해 클라이언트와 서버가 통신을 할 수 있게 된다.
CA(Certificate Authority) 이러한 SSL 방식을 적용하려면 인증서를 발급받아 서버에 적용시켜야 한다. 인증서는 사용자가 접속한 서버가 우리가 의도한 서버가 맞는지를 보장하는 역할을 한다. 인증서를 발급하는 기관을 CA(Certificate Authority)라고 부른다. 공인인증기관의 경우 웹 브라우저는 미리 CA 리스트와 함께 각 CA의 공개키를 알고 있다.
HTTPS는 인증서를 발급하고 유지하는데에 추가 비용이 발생한다. 개인정보와 같은 민감한 데이터를 주고 받는다면 HTTPS를 이용해야 하지만, 단순 정보 조회 같은 사이트는 HTTP를 적용하면 된다.
