0. Intro
브라우저로 어떤 웹사이트를 열게 되면 10 중 9 은 HTTPS (HTTP Secure) 를 사용하고 있는 것을 확인할 수 있다. 이는 웹사이트에서 보안이 적용된 통신 채널을 제공한다고 할 수 있다.
본인 같은 경우, 어떤 제품등을 구입한다던지 할 때, 웹사이트가 HTTPS 를 사용중이 아니라면 신뢰하지 못하고 다른 웹사이트를 찾아보는 편이다.
사실 HTTPS 의 적용은 거의 필수와 다름없다.
1. How HTTPS works?
1-1. public key & private key
공개키 (public key) 와 개인키 (private key) 는 암호화와 해독을 할 수 있는 열쇠(Key) 이다. 이 공개키와 개인키는 하나의 쌍으로 구성된다. 즉, 공개키로 암호화 된 메세지는, 오로지 쌍을 이루는 개인키로만 해독이 가능하다.
예를들어,
1) 우리는 일반적으로 브라우저에 naver.com 을 입력하게 되면 브라우저는 인터넷에게 "naver.com 내놔" 를 시전하게 된다. (DNS 를 통한 IP 를 찾아서 컨텐츠로 받음)
2) 그러면 naver.com 은 인증서를 보내주는데, 이 인증서는 public key 를 포함한다. 이 인증서는 Amazon CA 에서 받은거라고 하겠다.
2-0) 실제 네이버의 Root CA 는 DigiCert Gloabl Root CA 이다.
2-1) Root CA (아래에서 설명할 예정) 라는 곳에서 인증을 받은 인증서가 아닐 시, CERT_AUTHORITY_INVALID 같은 Your connection is not safe 같은 경고 화면을 볼 수 있다.
3) 인증서를 받은 나의 브라우저는 Amazon CA 를 알고, 그것의 public key 를 확인한다. "Amazon CA 안전한거 알고있고말고. Amazon 이 인정한 보안이면 너를 믿을 수 있지" 를 시전 후, 새로운 secret key 를 생성 (naver.com 의 public key 로 암호화 한 secret key) 해서 naver.com 으로 보낸다.
4) 왜냐하면 naver.com 의 public key 는 naver.com 이 소지한 private key 로만 해독할 수 있기 때문에 보안이 완성된다. 이로서 보안 통신이 가능해진다.
4-0) 물론, 해킹 아래에 완벽한 보안통신은 없다..
2. Root CA 에서 CA 는 무엇인가?
2-1. CA, Certificate Authority
인증기관이다. 보안적격 여부와 암호화와 복원을 위한 공개키들을 발급하고 관리하는 기관이다.
인증서 체인 이라는 것이 있다. HTTPS 를 사용하고자 하는 웹사이트들은 많고, 그 많은 것들에 대한 인증을 한 기관에서 모두 해줄 수 없기 떄문에 생긴 체인이라고 생각한다.
최상위에 있는 기관들을 Root CA 라고 부른다.
쉽게 설명하자면, 몇몇의 큰 기관들이 모여서 서로 신뢰할 수 있다고 확인한다. 그리고 인증서를 사용할 수 있다고 "인증" 하고 인증서 배포할 수 있게끔 한다. 그리고 그 기관들을 일정 기간 내로 계속 "아직도 신뢰할 수 있는가?" 를 확인하며 인증서 사용 기간을 연장시킨다.
intermediate 기관들은 이 Root 기관들로부터 "신뢰 가능함" 을 "인증" 받고 새로운 "인증"을 할 수 있는 자격을 얻는다. 그리고 최종적으로 우리가 배포하는 웹사이트에서 HTTPS 사용을 위해 "신뢰 가능함" 을 "인증" 받는 것이다.
거의 모든 브라우저들은 처음 배포 시 Root CA 의 public key 목록을 갖고있다. 만약, 브라우저가 배포될 때 없었던 CA 라고 하더라도 상위 CA 를 브라우저가 알고 있으면 새로운 CA 도 신뢰가 가능한 구조이다. (1-1 에서 브라우저가 Amazon CA 를 신뢰할 수 있었던 이유이다.)
2-1-0-fun-fact-1) 옛날에 한국 정부 기관에서 자기들끼리 Root CA 처럼 인증서를 뿌렸던 적 있었다. 그래서 웹사이트가 HTTPS 를 잘 사용하다가 인증서 갱신이 안 된 경우도 있었다. 물론, 더이상 그런짓을 하고있지는 않다.
2-1-0-fun-fact-2) 중국의 한 CA 에서 인증서를 너무 막 뿌리다가 (도메인 서버 확인도 안하고 너무 막 뿌리다가) 자격 박탈 당한 사례가 있다. 위키피디아에 적혀있다.
2-2. CSR, Certificate Signing Request
인증서 서명 요청.
인증서 발급을 위해 "나 신뢰 가능하니까 확인하고 확인서 줘" 하는 부분이다. 즉,"domain.name 인데, 이 domain.name 이 보함된 인증서 발급해줘" 라는 요청이다.
웹사이트에서 사용되는 인증서는 도메인 네임을 기준으로 확인한다. 어떤 말이냐 하면, CA 에서 발급받은 인증서가 domain2.name 이라고 할 때, 해당 인증서는 domain2.name 에서만 사용 가능한 인증서라는 뜻이다. 그렇기 때문에 인증서를 발급받을 때, 도메인 네임을 입력이 필요한 것 이다.
3. Self-Signed Certificate
그렇다면 Root CA 는 어떻게 인증을 받은 인증서를 받고 있을까? 최상위인데? 를 해결해주는 것이 Self-signed certificate 이다.
예를 들어, 앱을 배포한다고 하자.
1) private key 와 public key 를 만든다. (pair1)
2) private key 와 public key 를 위해 한쌍 더 만들어준다. private key2, public key2 (pair2) 라고 하겠다. 새로운 이 pair2 로 pair1 을 인증해주기 위한 키들이다.
테스트 환경에서 많이 사용해봤을, localhost 에서 https 테스트를 위해 사용해봤을, openSSL 등에서 많이 봤을것이다.
왜냐하면 브라우저가 신뢰하는 인증서 리스트에 없기 때문에, 아래와 같은 화면이 띄워진다.
댓글