HTTP(Hypertext Transfer Protocol)란?
HTTP는 인터넷에서 하이퍼텍스트를 교환하기 위한 통신 규약이다. 대표적으로 주고 받는 데이터 형태는 HTML이다.
- OSI 7계층중 응용계층에 속하는 프로토콜
- TCP/IP 위에서 작동
- Request와 Response로 통신
- 비연결지향(Connectionless)
- HTTP는 클라이언트가 요청(Request)을 서버에 보내고, 서버는 클라이언트에게 적절한 응답(Response)을 주고 연결(Connection)을 끊는 특성이 있다.
- 상태없음(Stateless)
- 커넥션을 끊는 순간 클라이언트와 서버의 통신이 끝나며 상태 정보는 유지하지 않는 특성이 있다.
- Method, Path, Version, Header, Body 등으로 구성됨
- https://img1.daumcdn.net/thumb/R1280x0/?scode=mtistory2&fname=https://blog.kakaocdn.net/dn/bkdJ4Q/btqK6AXLEtC/jBZzMuJBWzdLYmqILo5Ri1/img.png
HTTP 프로토콜의 특징 : 무상태(Stateless)란?
stateful은 서버가 클라이언트의 이전 상태를 보존한다는 의미이다.
반대로 무상태(stateless)는 서버가 클라이언트의 이전 상태를 보존하지 않는다는 의미이다.
승객: 서울에서 수원 가는 버스는 얼마인가요? 직원: 2500원입니다.
승객: 결제할께요. 직원: ?? 무엇을 구매하시는 건가요?
승객: 아까 말했잖아요. 서울에서 수원 가는 버스요!! 직원: … 왜 화내시죠?
기본적으로 기억상실증과 같다고 생각하면 좋다!
비연결지향이라는 특성 덕분에, 계속해서 커넥션을 유지하지 않기 때문에 리소스 낭비가 줄어드는 것은 아주 큰 장점이다.
그런데 문제는, 로그인을 통해 볼 수 있는 서비스 등 클라이언트가 정보를 유지해야 하는 Stateful한 성격의 서비스가 아주 많아졌다는 것이다. 그래서 쿠키 와 세션 혹은 JWT를 사용함으로써 이러한 단점을 보완한다.
기본적으로 HTTP는 단순한 텍스트 교환이므로, 속도가 빠르다는 장점이 있지만 누군가 네트워크에서 신호를 가로채면 내용이 그대로 노출되는 보안 이슈가 존재한다.
HTTPS
HTTPS(HyperText Transfer Protocol Secure)
: 인터넷 상에서 정보를 암호화하는 SSL (보안 소켓 계층) 프로토콜을 사용해 클라이언트와 서버가 자원을 주고 받을 때 쓰는 통신 규약
HTTP와 달리 텍스트를 암호화한다. (공개키 암호화 방식으로)
배경지식 : 대칭키 암호화 vs 비대칭키 암호화
- 대칭키 암호화
- 클라이언트와 서버가 동일한 키를 사용해 암호화/복호화를 진행함
- 공개키를 안전하게 교환하는 게 가장 중요한 부분.
- 키가 노출되면 매우 위험하지만 연산 속도가 빠름
- 비대칭키 암호화
- 1개의 쌍으로 구성된 공개키와 개인키를 암호화/복호화 하는데 사용함
- 키가 노출되어도 비교적 안전하지만 연산 속도가 느림
- 공개키로 암호화를 하면 개인키로만 복호화할 수 있다. → 개인키는 나만 가지고 있으므로, 나만 볼 수 있다. 내용 자체의 보안성을 유지할 수 있다.
HTTPS 흐름
- 클라이언트(브라우저)가 서버로 최초 연결 시도(TCP Hand-Shaking)를 함
- 서버는 SSL 인증서(공개키가 담겨있음)를 브라우저에게 넘겨줌
- 브라우저는 인증서의 유효성을 검사 → 대칭키를 발급데이터 간의 교환에는 빠른 연산 속도가 필요하기 때문
- 여기서 대칭키는 주고 받는 데이터를 암호화하기 위해 사용되는 키
- 브라우저는 이 대칭키를 보관하며 추가로 서버의 공개키로 세션키를 암호화하여 서버로 전송함
- 서버는 개인키로 암호화된 대칭키를 복호화하여 키를 얻음주로 쓰이는 공용 열쇠(세션키)를 전달하기 위해 서버의 개인키가 쓰이는 것.
- 즉, 2~5의 과정은 위에서 설명한 공개키 암호화에 해당!
- 이제 클라이언트와 서버는 동일한 대칭키를 공유하므로 데이터를 전달할 때 이 대칭키를 이용해서 암호화/복호화를 진행하며 통신
아래는 대화 버전.
클라이언트 : “안녕하세요? (경계중)”
서버 : “(당당) 우리 SSL 인증된 사이트야. 공개키도 같이 던져줄께”
클라이언트 : “유효한거 맞아요? … 맞네. 이제 말 놓자. 우리도 대칭키 하나 발급할건데, 앞으로 통신할 때 데이터들은 이걸로 보호해서 보낼거야. 너쪽 공개키로 한번 잠근거니까 너 개인키로 알아서 풀어”
서버 : “ㅇㅋ 내 개인키로 잘 풀리네. 확인”
HTTPS 사이트를 만드는 과정과 SSL
- 서버 개발자는 HTTPS를 적용하기 위해 공개키와 개인키를 만든다.
- 신뢰할 수 있는 CA(Certificate Authority) 기업을 선택하고, 그 기업에게 내 공개키 관리를 부탁하며 계약을 한다.
- 계약 완료된 CA 기업은 해당 기업의 이름, 서버 공개키, 공개키 암호화 방법을 담은 인증서를 만들고, 해당 인증서를 CA 기업의 개인키로 암호화해서 서버에게 제공한다.
- 서버는 이제 암호화된 SSL 인증서를 갖게 되었다. 이제 서버는 최초 연결시도마다 이 인증서를 클라이언트에게 건내준다.
- 클라이언트가 index.html 파일을 달라고 서버에 요청했다고 가정하자. 처음 연결 시도에선 HTTPS 요청이 아니기 때문에 CA기업이 자신의 개인키로 서버의 정보를 암호화한 인증서를 받게 된다.
- 브라우저는 CA기업의 공개키로 인증서를 해독한 뒤 서버의 공개키를 얻게 된다.CA 기업의 공개키는 브라우저가 이미 알고있다! (세계적으로 신뢰할 수 있는 기업으로 등록되어 있기 때문)
- ❓ CA 기업의 공개키는 어떻게 아는데?
참조
https://mangkyu.tistory.com/98
https://gyoogle.dev/blog/computer-science/network/HTTP & HTTPS.html
https://universitytomorrow.com/22
https://liveyourit.tistory.com/183
https://gyoogle.dev/blog/computer-science/network/HTTP & HTTPS.html
https://nukw0n-dev.tistory.com/11?category=940859
https://www.stevenjlee.net/2020/11/01/이해하기-http-vs-https-그리고-ssl-secure-socket-layer/
'CS > 네트워크' 카테고리의 다른 글
[CS 네트워크] JWT와 클라이언트-서버 통신 흐름 (0) | 2023.08.01 |
---|