728x90
반응형
HTTP (HyperText Transfer Protocol)
인터넷 상에서 하이퍼텍스트를 교환하기 위한 통신 규약
특징
- 80번 포트 사용
- Application 레벨의 프로토콜
- 상태를 가지도 있지 않은 stateless 프로토콜
- 보안 이슈: 암호화가 되지 않은 텍스트를 전송하는 프로토콜이므로, 누군가 네트워크에서 신호를 가로채면 내용이 노출되는 보안 이슈 존재 -> HTTPS 등장
HTTPS (HyperText Transfer Protocol Secure)
HTTP에 데이터 암호화가 추가된 프로토콜로, 인터넷 상에서 정보를 암호화하는 SSL 프로토콜을 사용하여 클라이언트와 서버가 자원을 주고받을 때 사용하는 통신 규약
특징
- 433번 포트 사용
- 공개키 암호화 방식 지원 : 네트워크 상 중간에 제3자가 정보를 볼 수 없도록 공개키 암호화를 지원하고 있다.
- HTTPS도 무조건 안전한 것은 아니다. (신뢰받는 CA기업이 아닌 자체 인증서 발급한 경우 등)
이때, HTTPS지만 브라우저에서 주의 요함, 안전하지 않은 사이트와 같은 알림으로 주의받게 된다.
* CA(Certificate Authority): 공개키를 저장해주는 신뢰성이 검증된 민간 기업
HTTPS 통신 흐름
- 애플리케이션 서버(A)를 만드는 기업은 HTTPS를 적용하기 위해 공개키와 개인키를 만든다.
- 신뢰할 수 있는 CA 기업을 선택하고, 그 기업에게 내 공개키 관리를 부탁하며 계약을 한다.
- 계약 완료된 CA 기업은 해당 기업의 이름, A서버 공개키, 공개키 암호화 방법을 담은 인증서를 만들고, 해당 인증서를 CA 기업의 개인키로 암호화해서 A서버에게 제공한다.
- A서버는 암호화된 인증서를 갖게 되었다. 이제 A서버는 A서버의 공개키로 암호화된 HTTPS 요청이 아닌 요청이 오면, 이 암호화된 인증서를 클라이언트에게 건네준다.
- 클라이언트 index.html 파일을 달라고 A서버에게 요청했다고 가정. HTTPS 요청이 아니기 때문에 CA기업이 A서버의 정보를 CA기업의 개인키로 암호화한 인증서를 받게 된다.
CA 기업의 공개키는 브라우저가 이미 알고 있다.(세계적으로 신뢰할 수 있는 기업으로 등록되어 있기 때문에 브라우저가 인증서를 탐색하며 해독이 가능하다.) - 브라우저는 해독한 뒤 A서버의 공개키를 얻게 되었다. 이제 A서버와 통신할 때는 얻은 A서버의 공개키로 암호화해서 요청을 날리게 된다.
이해가 잘 가지 않아 손으로 그려보았다.
참고 링크
https://mangkyu.tistory.com/98
https://jeong-pro.tistory.com/89
https://fistkim101.github.io/infra/2021-04-03-NEXTSTEP-%EC%9D%B8%ED%94%84%EB%9D%BC%EA%B3%B5%EB%B0%A9-%EB%AF%B8%EC%85%982-%EC%84%9C%EB%B9%84%EC%8A%A4%EB%B0%B0%ED%8F%AC%ED%95%98%EA%B8%B0.html
728x90
반응형