14. 보안 HTTP
- 서버 인증 : 클라이언트는 자신이 위조된 서버가 아닌 진짜와 이야기하고 있음을 알 수 있어야 한다.
- 클라이언트 인증 : 서버는 자신이 가짜가 아닌 진짜 사용자와 이야기하고 있음을 할 수 있어야 한다.
- 무결성 : 클라이언트와 서버는 그들의 데이터가 위조되는 것으로부터 안전해야 한다.
- 암호화 : 클라이언트와 서버는 도청에 대한 걱정 없이 서로 대화할 수 있어야 한다.
- 효율 : 저렴한 클라이언트나 서버도 이용할 수 있도록 알고리즘은 충분히 빨라야 한다.
- 편재성 : 프로토콜은 거의 모든 클라이언트와 서버에서 지원되어야 한다.
- 관리상 확장성 : 누구든 어디서든 즉각적인 보안 통신을 할 수 있어야 한다.
- 적응성 : 현재 알려진 최선의 보안 방법을 지원해야 한다.
- 사회적 생존성 : 사회의 문화적, 정치적 요구를 만족시켜야 한다.
- 모든 HTTP 요청과 응답 데이터는 네트워크로 보내지기전에 암호화 된다.
- HTTP(애플리케이션 계층) 밑에 SSL 혹은 TLS 라고 불리는 보안 계층을 제공해서 동작한다.
- 인코딩 및 디코딩 작업은 SSL 라이브러리 안에서 일어나기 때문에 다른 부분을 크게 변경할 필요는 없다.
- 암,복호화를 같은 키를 이용해서 하는 방식
- 속도가 빠르다
- 암,복호화를 서로 다른 키를 이용해서 하는 방식
- 인코딩을 하는 키는 공개되어있고 호스트만이 디코딩을 위한 키를 알고있다.
- 서버에 보내는 정보를 공개키를 이용해서 암호화해 전송할 수 있다.
- RSA 암호가 대표적
- 공개키 암호는 훌륭하지만 계산이 느리다
- 따라서 의사소통 채널을 수립할 때는 공개키 암호를 사용하고, 채널이 형성되면 임의의 대칭키를 생성해서 교환하고 이것을 이용해서 암호화하는 방식이 혼성 암호 체계
- 메시지를 요약한 뒤 개인키로 메시지를 암호화해서 '서명'으로 이용하는 방법
- 서명과 메시지, 공개키를 전송한다
- 전송 받은 사람이 이 메시지가 소유자가 보낸것인지 확인하기 위해서는 보내진 공개키로 서명을 복호화 한 뒤에, 메시지를 요약한 내용과 비교해서 일치하는지 확인한다.
- 일치 하지 않으면 변조된 메시지로 확인할 수 있다.
- 대상의 이름, 유효 기간, 인증서 발급자, 인증서 발급자의 디지털 서명이 들어있다.
- 공개키와 암호화 알고리즘도 같이 동봉되어 있다.
- HTTPS 웹 트랜잭션을 시작할 때 서버에서 인증서를 가져온다
- 인증서에 적혀있는 인증기관의 공개키를 이용해서 인증서의 서명을 검사한다.
- 브라우저는 신뢰할만한 서명기관의 공개키를 이미 알고 있으므로 이 키를 이용할 수 있다.
- URL이 HTTP 스킴을 가지고 있다면 80 포트로 연결하고 평범한 HTTP 요청을 전송한다.
- URL이 HTTPS 스킴을 가지고 있다면 443 포트로 연결하고 핸드 셰이크를 한 뒤에 암호화된 HTTP 요청을 보낸다.
- 클라이언트는 웹 서버의 433 포트로 연결한다.
- TCP 연결이 되고 나면 클라이언트와 서버는 암호법 매개변수와 교환 키를 협상하면서 SSL 계층을 초기화 한다
- 핸드 셰이크가 완료 되면 SSL 초기화가 완료되며, 클라이언트는 요청 메시지를 보안 계층에 보낼 수 있다.
- 프로토콜 버전 번호 교환 -> 양쪽이 알고 있는 암호 선택 -> 양쪽의 신원을 인증 -> 임시 세션 키 생성으로 이뤄진다.
- SSL은 클라이언트 인증서, 서버 인증서를 모두 사용할 수 있지만 클라이언트 인증서는 거의 사용되지 않는다.
- HTTPS 트랜잭션은 항상 서버 인증서를 요구한다.
- HTTPS 인증서는 X.509 인증서에 사이트 정보를 더한 인증서다.
- 날짜 검사 -> 서명자 신뢰도 검사 -> 서명 검사 -> 사이트 신원 검사 순으로 검사를 수행한다.
- 최상위 인증기간이 서명한 인증서에 있는 공개키로 서명한 인증서도 올바른 경로로 인지하고 받아들일 수 있다.
- 인증서에 들어있는 도메인을 실제 통신중인 도메인과 비교해 인증서를 도용하고 있는지 확인한다.