-
HTTP : 서로 다른 시스템들 사이에서 통신을 주고받게 하는 프로토콜
- 서버에서 브라우저로 전송되는 정보가 암호화되지 않는 문제
-
HTTPS : HTTP + SSL(보안 소켓 계층) 사용
- SSL : 서버와 브라우저 사이에 안전하게 암호화된 연결을 만들 수 있게 도와주고, 서버와 브라우저가 민감한 정보를 주고받을 때 해당 정보가 도난당하는 것을 막아줌
- HTTP 자체를 암호화 하는 것이 아닌, HTTP를 사용해서 운반하는 내용을 암호화(body와 header 모두)
-
왜 HTTPS를 사용해야할까?
-
보안성 : HTTP 자체를 가로챈다면, 해커가 중간에서 내용을 바로 알 수 있음
- HTTPS는 암호화해서 전송하므로 중간에서 가로채더라도 실제 내용을 알 수 없음
-
SEO(검색엔진 최적화) : 구글은 HTTPS 웹 사이트에 가산점을 줌
- 검색엔진에 빈번하게 노출되기 위해 HTTPS는 불가피
- AMP(가속화된 모바일 페이지)를 만들 때 HTTPS를 사용해야만 함
- AMP : 모바일 기기에서 컨텐츠를 훨신 빠르게 로딩하기 위한 방법(Google에서 만듦)
-
-
SSL(Secure Sockets Layer) : Netscape Communications Corporation에서 웹 서버와 웹 브라우저간의 보안을 위해 만든 프로토콜
- SSL 업그레이드 버전이 TLS이나 동일하게 다루는 곳도 있음
- 공개키/개인키, 대칭키 기반으로 사용함 (두 방식 모두 적절히 사용)
- 대표적으로 Let's Encrypt, AWS Certificate Manager 등이 SSL 인증서를 무료로 발급해줌
-
대칭키 방식 vs 공개키/개인키 방식 차이
- 대칭키 : 동일한 키로 암호화 복호화 하는 방식
- 암호화/복호화가 쉬움
- 전달할때 문제
- 공개키 : 서로 다른 키로 암호화/복호화 수행
- 비대칭키 방식으로도 불림
- 암호화 시 공개키 / 복호화 시 개인키
- 공개키로 암호화한 데이터는 개인키로만 복호화가능
- 공개키는 노출되어도 됨
- 대칭키 연산보다 암호화 연산 시간이 더 수행되어 비용이 더 높다는 단점
- 개인키로 암호화한 것은 공개키로 복호화 가능(서로 한쌍으로 반대도 가능)
- 대칭키 : 동일한 키로 암호화 복호화 하는 방식
-
SSL 통신 과정
1) 공개키 방식으로 대칭키 전달
2) 대칭키를 활용하여 암호화, 복호화 하며 통신 진행- 한쪽의 대칭키를 다른쪽의 공개키로 암호화해서 전송하면 반대편에서 자신의 개인키로 복호화하여 그 반대편의 대칭키를 알아내고 이 대칭키를 바탕으로 서로 통신
-
사용자가 접속한 사이트가 유효한지 확인? 제3의 인증기관 확인 필요
- 특정 사이트는 사이트 인증서(인증기관에서 발급) 필요.
-
특정 사이트에서 사이트 인증서 발급 과정
- 특정 사이트 : 사이트 정보 + 사이트 공개키를 인증기관에 전달
- 인증기관 : 사이트 인증서 발급 전 전달받은 데이터(사이트 정보 + 공개키) 검증
- 인증기관 : 성공적으로 검증 하고나면 인증서를 생성하기 위해 인증기관은 인증기관 개인키로 서명 -> 사이트 인증서 생성
-
사용자가 특정 사이트 접속 과정
-
사전 과정
-
인증 기관은 사용자에게 인증기관 공개키 전달
-
사용자 브라우저에 자동으로 내장(사용자가 사이트에 접속하기 전)
-
실제 과정
-
사용자 특정 사이트 접속 요청
-
사이트 : 사용자에게 사이트 인증서 전송(신뢰받은 사이트임을 인증하기위함)
-
사용자 : 브라우저 내장되어 있는 인증기관 공개키로 사이트 인증서를 복호화해서 검증
(사이트 인증서를 해독하면 사이트 정보 + 사이트 공개키 얻을 수 있음)
- 이전 인증기관에서 개인키로 암호화 -> 공개키로 복호화 가능(서로 한쌍) -
사이트 공개키를 활용해 사용자 대칭키를 암호화
-
암호화한 대칭키를 사이트에게 전달
-
사이트는 자신의 개인키로 암호문 해독하여 사용자의 개인키를 얻음
-
이후 SSL통신 가능
-
--> 즉 SSL은 인증기관을 포함하기에 안전한 접속(사용자가 접속하려는 사이트가 믿을만한 사이트인지 확인 가능)
- 인증기관의 개인키로 암호화 -> 인증기관의 공개키로 복호화
