[SSL/TLS] CA를 이용한 서버 인증
서버 인증
이전에 클라이언트와 서버는 각각의 공개키를 공유하고 이를 바탕으로 대칭키를 만든다고 하였습니다.
이후 대칭키로 데이터를 암복호화 하여 통신한다고 했는데
가장 중요한건 클라이언트가 서버를 어떻게 믿을것인가 입니다.
이를 가능하게 하는것이 인증서를 통한것입니다.
인증서를 통해 서버가 믿을만한 놈인지 구별할 수 있습니다.
인증서
이런 화면 많이 본적 있을겁니다. 이것이 https 통신을 하고 있다는 의미인데요.
정확히는 ssl/tls인증방식을 사용하고 있다는것입니다.
인증서는 다음과 같은 정보를 가지고 있습니다.
1. 서비스 정보(인증서를 발급한 CA, 서비스의 도메인 등)
2. 서버 측 공개키(공개키, 공개키 암호화 방법)
3. 지문, 디지털 서명 등
여기서 처음볼 수 있는 CA, 지문, 디지털 서명에 대해서 알아보겠습니다.
CA(certificate Authority)
CA는 인증서를 발급해주는 기관입니다. -> RootCA라고도 하는데, 신뢰할 수 있는 기관입니다.
SSL/TLS통신을 하기위해서는 서버가 믿을만한 놈이지 알아야 한다고 했습니다.
믿을만한 놈인지 인증하는것이 인증서입니다.
즉 CA를 통해 인증받은 서버는 클라이언트입장에서도 믿을만하다고 판단하는것입니다.
참고로 클라이언트는 미리 CA와 그에 해당되는 공개키 리스트들을 가지고 있습니다.
OS나 브라우저 상에 등록되어 있습니다.
실제로 구글 보안설정 -> 인증서관리 -> 신뢰할수 있는 루트 인증 기관에서 확인 할 수 있습니다.
위의 사진과 같이 A회사는 CA에게 인증서 요청을 합니다.
4번째 과정에서 CA의 개인키로 서명을 하기에 CA는 개인키가 노출되지 않게 하는것이 중요하다고 할 수있습니다.
(인증서 발급으로 먹고사는 회사인데 개인키 털리면 뭐...)
실제로 인증서를 확인해보면 서명, 지문을 확인 할 수 있습니다.
그리고 위 사진에서 DigitalCert ~RootCa -> DigitalCert ~Server CA -> *.facebook.com 이런식으로 되어 있는것을
인증서 체인이라고 합니다.
실제로 우리가 facebook에 접속했을때 RootCa에게 인증서를 발급받는것이 아닌 해당그림에서는 ServerCA에게 인증서를 발급받습니다.
1.*.facebook에서 받은 인증서는 상위 기관인 ServerCA의 개인키로 작성한 인증서
2.Server CA에서 받은 인증서는 RootCa의 개인키로 작성한 인정서
3.RootCA는 자신의 개인키로 작성한 인증서입니다.
왜 3번은 자신의 개인키로 작성하냐면 상위 인증기관이 없기에 그렇습니다.
그렇기에 앞에서 말했듯이 RootCA는 개인키보관을 굉장히 중요시해야합니다.
<참고>
3번과정을 잘 살펴보면 우리도 RootCa를 만들 수 있습니다.
물론 우리는 이걸 사설인증서라고 합니다.
이런 사진을 본적이 있을겁니다.
이건 위에서 언급한 브라우저나 OS상에 등록되지 않은 RootCA이기 때문입니다.
사설인증서를 만드는것은 openssl과 같은 툴로 생성해볼 수 있습니다.
서버인증?
클라이언트가 서버인증을 하기위한 절차를 한번 정리해보겠습니다.
가장 중요한건 클라이언트 입장에서
서버가 믿을만한 놈인가??입니다.
1.서버가 RootCA에게 인증서 발급 요청
A회사는 외부 클라이언트의 신뢰를 얻기위해 RootCA에게 인증서 발급을 요청합니다.
위에서 언급했듯이
CA Name: RootCA 호스트 이름
public key(지문): A회사의 공개키를 해시화
digital signing: 지문은 RootCA의 개인키로 암호화입니다.
2.클라이언트가 서버에게 인증서 요청(서버가 믿을만한 놈인가? 판단하기 위함)
클라이언트는 서버가 가지고 있는 인증서를 받습니다.
앞에서 언급했듯이 클라이언트는 브라우저나 OS에 RootCA(신뢰가능한 인증기관)을 미리 저장해둔다고 했죠?
그리고 서버가 가지고 있는 요소 중 CA Name은 RootCA hostname이구요
즉 클라이언트입장에서는 미리가지고 있는 RootCA리스트를 확인해서 "아 인증할 수 있는 기관이구나"라고 인증서를 통해 확인할 수 있습니다.
인증서는 신뢰할만하다는것을 확인했고 이후 하나의 절차가 더 있습니다.
Digital Signing은 RootCA의 개인키로 암호화 한다했는데, 이건 OS나 브라우저에서 가지고 있는 RootCA의 공개키를 이용해 보고화 할 수 있죠
(Digital Signing -> 복호화(RootCA의 공개키) -> Public Key)가 되겠죠
클라이언트 입장에서는 가지고 있는 RootCA인증기관과 공개키를 가지고 복호화한 public key(지문)
= 인증서에 적힌 pulblic key(지문)
이 확인되면 믿을만 하다고 판단합니다.
이렇게 복잡하게 하는 이유는 중간에 누가 인증서를 RootCA Name만 같게하고 바꿔치기 한다면 신뢰하면 안되는 기관인데 신뢰할 수 있기 때문입니다.
3. 믿을만한놈인거 OK -> 이제 대칭키로 암호화 통신하자
클라이언트는 대칭키를 생성하고 이를 서버의 공개키로 암호화합니다.
이후 서버는 자신의 개인키로 복호화 하여 데이터 통신에 필요한 대칭키를 공유합니다.
이제 대칭키를 가지고 암호화 통신합니다
크게 3가지 입니다.
이러한 과정을 handshake라는 과정을 통해 이루어지는데
우선 간략하게 흐름만 살펴보았습니다.
이후 글에서는 handshake에서 다루어 보겠습니다.
참고
https://babbab2.tistory.com/5?category=960153
이거 너무 잘되어있어서 제꺼 글 이해안되면 참고하시면 좋을거 같습니다.