[ #12 ] 클러스터 보안 - 3

1. TLS가 제공하는 이점들

기밀성 (암호화)

이전 포스팅에서 공부했던 암호화에 해당하는 항목입니다.

서버와 주고 받는 데이터가 스니핑👀 되는 것을 방지합니다.

패킷이 오가는 것을 훔쳐 볼 순 있어도 안전하게 암호화 된 패킷이라 복호화 할 수 없기 떄문에

데이터는 훔쳐볼 수 없습니다.
데이터 무결성

통신 도중 데이터가 제 3자에 의해 악의로 변경될 일이 없습니다.

1번 기밀성과 같은 선상에서 보시면 됩니다.

서로의 대칭키를 RSA 알고리즘을 통해 안전하게 공유한 후에 암호화하여 통신하기 때문에

제 3자가 대칭키를 알아내지 않는 한 중간에서 암호화된 데이터를 임의로 수정하지 못하겠죠.
서버 인증

1, 2번은 지난 포스팅에 공부했던 암호화 알고리즘을 통해 가능하다고 보여져요.

근데 만약 위의 암호화 방식으로만 서버와 클라이언트가 통신을 한다고 가정해 봅시다.

서버와 나는 암호화를 통해 통신하기 때문에 아무도 데이터를 훔쳐볼 수도 건들 수도 없겠지!

여기까지도 좋습니다 근데 만약 서버가 신뢰할 수 없는 서버라면 얘기가 달라지겠지요?

요즘 웹 브라우저에 성가신 팝업이 표시되는 경우

웹을 탐색하는 도중에 무료 경품을 제공한다거나 기기에 문제가 있다고 경고하는 팝업이나 알림이 표시되는 경험은 한번씩 해 보셨을거라고 생각합니다.

이러한 유형의 팝업은 대개 사기성 광고이며, 사용자를 속여 사기꾼에게 개인 정보나 돈을 제공하도록 하기 위해 만들어졌습니다.

이런 서버에 아무리 암호화된 데이터를 보낸다 한들 서버가 사기꾼놈의 서버라면 정말 큰 문제지요.

이처럼, 서버와 클라이언트 간 통신을 할 때는

서버가 신뢰할 수 있는 서버라는 것을 확인하는 작업이 필요합니다.

이럴 때 사용하는 것이 바로 ‘인증서’ 입니다!!!

이번에 공부할 포스팅에서 왜 인증서라는 것에 대해 공부하는지 이제 아시겠죠?

자 그럼 이제 시작해 봅시다.

2. 인증서란 ?

인증서라는 것이 무엇일까요? 이름부터 이미 감이 오지 않나요?

바로 위에서 서버가 신뢰할 수 있는 진짜 서버 임을 확인하기 위해 필요한 것이 바로 인증서 입니다!

인증서에는 다음과 같은 정보들을 포함하고 있습니다.

서비스 정보(인증서를 발급한 CA, 서비스의 도메인 등)
서버 측 공개키(공개키, 공개키 암호화 방법)
지문, 디지털 서명 등

여러분이 지금 보고계신 이 블로그도 인증서를 가지고 있답니다.

주소창의 가장 왼쪽에 🔒 보이시나요?

자물쇠가 잠겨있다는 건 이전 포스팅에서 공부했던 HTTPS 통신이라는 뜻입니다 보안되어 있다는 말이지요

제 블로그는 GitHub Pages를 통해 만들어졌는데요 개인 도메인도 무료로 HTTPS를 지원하지요.

그럼 깃헙의 인증서를 한번 들여다 봅시다.

앞서 말했듯 서버의 공개키, 서명, 지문, 발급자 정보 등이 포함되어 있는것을 확인할수 있습니다!

이것들이 인증서에서 어떤 역할을 하는지는 차차 알아봅시다.

그러기 전에 먼저,

이 인증서는 어디서 어떻게 생성할까요?

3. CA (Certificate Authority)

CA는 인증서를 발급해주는 기관으로, Root Certificate라고 부르기도 합니다.

CA는 아무 기업이나 할 수 있는 게 아니라 신뢰성이 엄격하게 공인된 기업들만 할 수 있습니다.

TLS 통신을 하려면 이 CA를 통해서 인증서를 발급받아야 합니다.

먼저, 미리 알아둘 것은 CA는 자체적으로 공개키와 비밀키를 가지고 있습니다.

CA의 비밀키는 절대 누설 되어선 안 되며, 이것이 노출되는 바람에 디지노타 라는 회사가 파산된 사례도 있습니다.

4. CA에서 인증서 발급받기

자 이제 CA로부터 인증서를 발급받는 방법을 알아 봅시다.

먼저 그림으로 전체적인 메커니즘을 보고 넘어 갑시다.

자 실제 인증서를 통해 확인해 봅시다.

먼저, 발급 받고자 하는 기관은 자신의 사이트 정보(도메인 등)과 공개키를 CA에게 제출합니다.

그러면 CA는 검증을 걸친 후 발급 받고자 하는 서버의 공개 키를 해시(SHA-256 등) 합니다.

이렇게 해시한 값을 Finger Print(지문) 이라고 합니다.

이제 이 지문을 CA의 비밀키로 암호화 하고,

인증서의 발급자 서명으로 등록합니다.

이렇게 서명된 것을 디지털 서명 (Digital Signing) 이라고 합니다.

이제 CA는 서버에게 이 디지털 서명, 발급자 정보 등등이 등록되어 있는 인증서를 발급해 줍니다.

이러한 방식처럼,

상위 인증 기관이 하위 인증서가 포함하고 있는 공개키 (인증서)를 상위 기관의 비밀키로 암호화 하여

상호 보증하게 되는 것을 인증서 체인(Certificate Chain) 이라고 합니다.

내가 발급받는 CA 기관이 Root CA가 아니라면, 이 CA 기관마저 또 상위 CA에게 인증서를 발급받은 것입니다.

보통 3단계에 걸쳐서 인증서 체인이 일어나는데,

Github.com의 인증서는 그 상위 인증서인 Digicert SHA2 CA(Intermediate CA)의 비밀키로 암호화 된 것이며,
Digicert SHA2 CA인증서는 그 상위 인증서인 Digicert High Assurance EV Root CA 의 인증기관의 비밀키로 암호화 된 것입니다.
Digicert High Assurance EV Root는 상위 인증기관이 없는 Root CA이기 때문에 Self-Signed 되어 있습니다.

Self-SIgned (스스로 보증) 이란,

자신의 인증서를 해시한 후, CA가 아닌 자신의 비밀키로 암호화 하여 서명으로 등록

하는 것을 말합니다

이게 바로 인증서 체인입니다.

5. SSL(TLS) 인증서의 작동원리

CA에서 발급받은 인증서를 통해 서버의 신뢰성을 인증한다고 했었습니다.

근데 클라이언트는 이 인증서가 CA에서 발급받은 것인지, 중간에 누가 조작한 것인지를 어떻게 확인할까요?

먼저 알아 두어야할 것은, 클라이언트들은 CA 리스트들을 이미 가지고 있습니다.

OS를 설치할 때 PC에 포함되어있고 브라우저가 이를 읽어옵니다

크롬의경우 Setting -> Privacy and security -> Manage certificates 를 클릭하면

설치되어있는 CA 리스트르 보여줍니다.

직접 확인해 봅시다.

먼저 우측상단의 땡땡이 클릭후 Settings클릭!

Privacy and security 클릭후 securit클릭!

Manage certificates클릭!

엄청 많은 인증서가 보이시지요 ㅎㅎ 그중에는 깃헙인증서의 상위 인증기관인 Digicert의 인증서도 보이는군요

맥의경우 Keychain Access앱을 클릭하면 똑같은 위치로 이동할 수 있습니다.

자 이제 정말 어떻게 인증하는지 알아보자구요.

a. 인증서 신청하기

서버A는 자신이 믿을 수 있는 서버임을 인증하기 위해 CA에서 인증서를 발급받으려 합니다.

그러기 위해선 자신의 사이트 정보와 사이트의 공개키를 CA에 제출합니다.

그러면 CA는 검증을 걸친 후 다음과 같은 과정을 거칩니다

제출받은 서버의 공개키를 해시하여 Finger Print를 생성하고
Finger Print를 CA의 비밀키로 암호화(Digital signing)

그리고 서버에게 이런 정보들이 들어 있는 인증서를 발급해 줍니다.

서버는 이제 자신이 진짜 서버임을 인증해줄 인증서를 갖고 있는 것입니다.

b. 클라이언트의 인증된 서버 확인방법

아무개씨가 서버에 접속 하려고 합니다. 근데 신뢰할 수 있는 서버에 접속을 해야겠지요

이전 포스트에서 배운 TLS 통신을 통해 서버는 CA에서 발급받은 인증서를 아무개씨에게 넘깁니다

근데 그 과정에서 해커 가 인증서를 자신의 인증서를 바꿔치거나 인증서의 공개키를 자신의 공개키로 바꿨다면

이 인증서가 무결성은 어떻게 확인할까요?

앞전에 말했었지요, 클라이언트는 이미 모든 CA리스트의 공개키를 가지고 있다는 것을요

우선 아무개씨 OS가 갖고있는 CA리스트(인증받은 Root CA들)에 있는 놈인지 확인합니다.

만약에 이 리스트에 없다면 바로 신뢰할 수 없는 사이트가 되겠습니다.

만약 리스트에 있는경우에는 해당 CA 기관의 공개키로 서버 인증서의 서명(Digital Signing)을 복호화 합니다.

(CA는 자신의 비밀키로 인증서를 암호화를 하였으니, 공개키로 복호화가 가능합니다.) 디지털 서명을 복호화 하면, 인증서 내용을 해시한 값이 나오겠죠?

많이 햇갈릴 수 있지만 CA의 검증 과정을 되짚어 보면 이해하기 한결 쉬우실 겁니다.

CA의 검증과정에서 서버의 공개키를 해쉬값으로 만든 FingerPrint값이 있었구요.
CA의 비공개키로 그 FingerPrint값을 암호화 하여서 Digital Signing을 만들었습니다

-> 그말은 즉슨 CA의 공개키로 복호화한 Digital Signing값은 FingerPrint이며!

-> 해당 서버의 공개키를 해쉬화 한 값과 일치해야 해야만 한다는 말이지요!

일치하지 않는다면 인증서가 위조되었다는 말과도 같습니다.

c. 암호화 통신하기

서버의 인증서의 공개키를 해쉬한 값과,

OS에 존재하는 인증서의 공개키로 해당 서버 인증서의Digital signing을 복호화한 값이 일치 했다면 믿을만한 서버이기에 통신을 하면되겠죠?

우리는 이미 서버의 공개키를 알고있지요?

통신에 사용할 대칭키를 서버의 공개키로 암호화하여 서버에 보냅니다.

서버는 자신의 비공개키로 이를 복호화하여 이제 더욱 저렴한비용의 대칭키 방식으로 클라이언트와 통신을 할 수가 있겠습니다.

이전[ #11 ] 클러스터 보안 - 2

다음첫 면접