1. HTTPS
ㆍ 보안이 강화된 HTTP
ㆍ 데이터 내용을 암호화하여 통신하도록 설계된 프로토콜
ㆍ SSL/TLS 보안 계층을 이용함
ㆍ 기본 포트: 443
2. HTTPS 장/단점
ㆍ 데이터 보안(은행, 쇼핑몰, 정부사이트에서 특히 강점)
ㆍ 검색 엔진에서 우선 순위 선점
ㆍ HTTPS 설치 및 SSL 인증서 유지에 추가 비용 발생
ㆍ 모든 사이트를 HTTPS로 할 경우 암호화 과정에서 오버헤드가 길어질 수 있음
ㆍ 접속이 끊길 시 재인증이 필요함
3. KEY
대칭키
ㆍ 1개의 암호키로 암호화, 복호화 하는 것
ㆍ 클라이언트와 서버가 같은 키를 가지고 있음
ㆍ 장점: 암호화, 복호화 속도가 빠름 = 대용량 데이터에 적합
ㆍ 단점: 불특정 다수와 통신할 때 안전하지 않음
비대칭키
ㆍ 서로 다른 2개의 키로 암호화, 복호화 하는 것
ㆍ 공개키: 모두가 접근 가능한 키
ㆍ 개인키: 본인을 제외한 누구도 접근이 불가능한 키
ㆍ 2개의 키로만 암호화, 복호화 할 수 있음
ㆍ 장점: 대칭키보다 안전하게 데이터를 송수신 할 수 있음
ㆍ 단점: 암호화, 복호화 속도가 느림
4. SSL(TSL)
ㆍ 클라이언트와 서버가 데이터를 암호화해 통신할 수 있도록 하는 프로토콜
ㆍ 대칭키, 공개키 암호화 방식 사용
ㆍ SSL 3.0 = TLS 1.0 (즉, SSL의 업데이트 버전이 TSL)
5. HTTPS 암호화 과정 (SSL 동작 과정)
Handshake
ㆍ 클라이언트와 서버가 같은 키를 가지기 위해 거치는 과정
1. Client Hello
ㆍ 클라이언트가 서버에 1) 랜덤 데이터(문자열) 2) 브라우저가 지원하는 암호화 방식 전송
2. Server Hello
ㆍ 서버가 클라이언트에 1) 랜덤 데이터(문자열) 2) 서버가 지원하고 선택한 암호화 방식 3) SSL 인증서 전송
3. 클라이언트의 SSL 인증서 신뢰성 판단
ㆍ 클라이언트는 SSL 인증서가 CA 인증서에 있는지 확인함
ㆍ CA 인증서가 맞다면 SSL 인증서를 복호화 함
4. 서버에 대칭키 전송
ㆍ 클라이언트는 Client Hello, Server Hello 과정에서 주고 받은 랜덤 데이터를 조합하여 대칭키 생성
ㆍ 대칭키 -> 공개키로 암호화 하여 서버에 전달
5. Handshake 종료
ㆍ 서버는 클라이언트로부터 받은 공개키를 복호화하여 전달 받음
ㆍ 클라이언트와 서버는 각자의 키를 이용하여 세션키를 생성함
ㆍ 클라이언트와 서버가 같은 키를 같게 되었으므로 Handshake 종료
Session
ㆍ 클라이언트와 서버가 데이터를 주고 받는 단계 = HTTP 통신
ㆍ 대칭키를 이용하여 암/복호화를 진행함
Session Close
ㆍ 데이터 전송이 끝나면 세션을 종료하여 SSL 통신을 마침
ㆍ 세션이 종료되면 세션키를 폐기함
참고
ㆍhttps://velog.io/@usreon/%EC%9D%B8%EC%A6%9D%EB%B3%B4%EC%95%88-HTTPS-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C
ㆍ https://brunch.co.kr/@swimjiy/47
ㆍ https://mommoo.tistory.com/103
ㆍ https://nuritech.tistory.com/25
