728x90
이 글은 ASAC 06기를 수강하며 강의 자료 참고 및 추가 자료 수집을 통해 작성된 글입니다.
HTTPS (HTTP Secured, TLS)
- 웹 통신 내 End-to-End 회선 보호
- SSL(Secure Sockets Layer) 혹은 TLS(Transport Layer Security) 프로토콜을 통해 HTTP 보안 강화
HTTPS 목적
요청을 보내고, 응답을 받는 두 주체 (End-to-End)만 HTTPS 요청 및 응답을 읽을 수 있게 암호화
- 목적 : MITM(Man-In-The-Middle) 공격 방지
- 스니핑 (Sniffing) : Wireshark 사용 모든 웹 서핑 패킷 도청 가능
- 패킹 주입 (Packing Injection) : DHCP/ARP로 LAN 내 컴퓨터 인지 후 패킷을 대신 받아 조작 주입
- ARP Spoofing -> 위변조
- Sniffing -> 도청 혹은 가로채기
- ARP Spoofing -> 위변조
- 세션 하이재킹 공격
- SSL 스트리핑 등
대칭키와 비대칭키
- 비대칭키 => 알고리즘이 매우 복잡해서 느리다. 비밀키만 잘 관리하면 대칭키보다 안전하다.
- 공개키는 누가나 볼 수 있고 노출 되어도 안전.
- 노출되어도 안전한 공개키를 클라이언트에게 공유하여 암호화 통신을 위한 시작을 연다.
- 비대칭 암호화는 갑을 관계를 내포한다. 갑(비공개키를 가진 서버), 을(공개키를 가진 클라이언트)
GIT의 경우 SSH 통신 유저가 갑(비공개키를 가짐), 리포지토리들이 을(공개키를 가짐)
- 대칭키 => 매우 빠르다. 키 하나기 때문에 노출되면 보안에 매우 위험.
- 연산속도가 빨라 매번 클라이언트와 서버가 요청/응답을 주고받을 때 성능 영향을 안준다.
CA(Certification Authority)
- SSL 인증서를 발급하는 기관, 신뢰할 수 있는 기관
- 인증 기관에 의해 인증된 서버인지 = 인증 기관에 의해 암호화된 '서버의 공개키' 인지
- 피싱 방지 : 클라이언트가 실제로 도메인을 소유하고 있는 올바른 서버와 통신하고 있는지 확인 목적
HTTPS 통신 절차
HTTPS 통신 시작 시 절차. => 2쌍의 비대칭키로 1쌍의 대칭키 만들기
일종의 hand shaking이다.
- CA 비공개키(전 세계에 하나)로 서버의 공개키를 암호화 한다.
- 서버에는 매 클라이언트를 위한 비대칭키 페어를 가지고 있다.
- 웹 브라우저가 암호화된 서버의 공개키를 받는다.
- 브라우저는 요청을 할 때 CA의 공개키로 복호화 하여 서버의 공개키를 얻는다.
- CA 공개키는 브라우저에 저장되어 있다. (없다면 인증서 다운로드 하면 됨. 브라우저 혹은 로컬 PC에)
- 서버와 브라우저는 같은 PRE MASTER KEY를 가지게 된다.
- PRE MASTER KEY -> MASTER KEY -> SESSION KEY
- 결국 같은 SESSION KEY(대칭키)를 브라우저와 서버가 가지게 된다.
최종적으로 클라이언트와 서버는 대칭키로 통신을 하게 된다.
HTTPS는 비대칭키와 대칭키 암호화 전략을 모두 쓰기 때문에 장점만 취함.
- 비대칭키 장점 -> 안전하다
- 대칭키 장점 -> 빠르다
서버와 클라이언트가 비대칭키를 주고받아 이를 통해 생성한 대칭키로 암호화.
-> 유출되어도 안전, 인증 시 대칭키 알고리즘 사용으로 빠르다.
비대칭키 2 PAIR(CA 1 PAIR, 서버 1 PAIR), 대칭키 1 PAIR(서버와 브라우저가 같은 대칭키를 가지게 됨)
728x90
'ASAC' 카테고리의 다른 글
[ASAC 06] Shell, Linux 명령어 (0) | 2024.09.12 |
---|---|
[ASAC 06] CORS (1) | 2024.09.11 |
[ASAC 06] 웹 저장소 (쿠키, 세션, 웹 스토리지) (4) | 2024.09.11 |
[ASAC 06] 프록시 사용 목적, 기능과 예시 (1) | 2024.09.01 |
[ASAC 06] 캐시 2편 - 헤더 설정 (1) | 2024.09.01 |