[Web] SSL 인증서에 대한 이해(사전 지식, 정의, 동작원리, 인증서 비교)

SSL 인증서를 알기 위해서 알아야 할 사전 지식이 있습니다. 이에 대한 내용부터 알아보도록 하겠습니다.

HTTP

HTTP 란 Hyper Text Transfer Protocol 의 약자로 인터넷 통신을 위해 사용되는 프로토콜입니다. 프로토콜은 컴퓨터 간의 의사소통에 사용되는 언어라고 생각하시면 될 것 같습니다. 사람 간의 대화에서도 서로 같은 언어를 써야 소통이 가능하듯이 컴퓨터도 의사소통을 위해 언어를 통일 시켜야 했고 이를 망라하여 프로토콜이라고 합니다. 즉 HTTP 도 컴퓨터간의 대화를 위한 언어 중 하나라는 것이죠.

웹에서는 서버와 클라이언트가 HTTP 를 통해 소통 하기 때문에 몰라서는 안되는 부분입니다. 백앤드 개발자는 두 말 할 것 없고 프론트 개발자도 마찬가지죠. 이렇게 소통을 하는데 있어서 정보를 평문으로 전송을 하게 되는데 여기서 문제점이 발생합니다. 정보가 전달되는 네트워크에서 중간에 정보를 가로챌 수 있다는 점이죠. 이러한 보안 문제를 해결하기 위해 정보를 보낼 때 암호화 해서 보내는 방법이 등장하였습니다. 이것이 바로 HTTPS 의 시작입니다.

 

HTTPS

HTTPS 는 HTTP와 Secure 가 합쳐진 것으로 HTTP 와 큰 틀은 다르지 않습니다. 같은 통신 프로토콜이며 쓰이는 곳 또한 동일합니다. 앞에서 말했던 대로 HTTP 가 하던 역할을 대신 하여 보안 문제를 해결하기 위해 나왔으니 당연하겠죠. 아직 웹사이트 내에서 HTTPS 가 차지하는 비율은 많지 않지만 점점 늘어가고 있습니다. 구글, 네이버 등 검색 엔진들도 HTTPS 프로토콜을 사용하는데 있어서 더 우대해주기 때문이죠. 그렇다면 HTTPS 는 어떻게 보안 문제를 해결하였을까요? 알아보도록 하겠습니다.

 

SSL

SSL 역시 프로토콜 중 하나로서 Secure Socket Layer 의 약자입니다. 이름에서 알 수 있듯이 인터넷 상에서 주고 받는 데이터를 보호하기 위해 등장하였습니다. 그러면 여기서 한 가지 의문이 생깁니다. SSL 과 HTTPS 는 같은 것이 아닐까? 라는 의문이 말이죠. 결론부터 말하면 둘은 다릅니다. 아래 이미지를 보시죠.

프토토콜 layer

둘의 차이는 인터넷과 웹의 차이와 같습니다. 인터넷은 컴퓨터를 통해 정보를 주고 받는 네트워크라고 볼 수 있고, 웹은 인터넷을 통해 사용가능한 서비스입니다. 마찬가지로 HTTPS 도SSL 프로토콜 위에서 돌아가는 프로토콜로서HTTP 이 외에도 이미지에서 볼 수 있듯이 FTP,NNTP,XMPP 등도 SSL 위에서 돌아가며 보안을 유지할 수 있습니다.

 

TLS

TLS 란 SSL 와 동일하며 이름만 변경한 것 입니다. 네스케이프에서 보안 문제를 해결하기 위해서 SSL 을 발명하였고, 이것이 표준이 되면서 TLS 라는 이름으로 바뀌게 되었습니다. 현재는 둘을 혼용해서 사용하고 있지만 SSL 이라는 이름을 더 많이 사용하고 있으며, 오픈소스의 이름 역시도 OpenSSL 입니다.

 

SSL 인증서란?

SSL 인증서 란 클라이언트와 서버 간의 통신의 안정을 보증해주는 문서입니다. 클라이언트가 서버에 접속하게 된다면 서버는 클라이언트에게 이 인증서를 전달해서 신뢰를 얻게 됩니다. 인증서를 사용함으로서 다음과 같은 이점을 얻을 수 있습니다.

• 스니핑 방지

  로그인을 통한 아이디, 비밀번호 부터 전자상거래 중 카드 정보까지 여러 개인 정보에 대해 암호화 되기 때문에 설령 유출되더라도 문제를 막을 수 있습니다.

• 피싱 방지

  유사사이트를 만들어 사용자로서 부터 주요 정보를 빼내는 경우도 있습니다. 이런 사이트들은 SSL 인증서를 발급해주지 않기 때문에 이를 해결할 수 있습니다.

• 데이터 변조 방지

  데이터가 전송 될 경우, 해당 데이터에 접근하여 데이터의 값을 바꾸는 문제점도 있습니다. 이 역시도 인증서를 통해 해결 가능합니다.

   

SSL 인증서의 암호화

SSL 은 크게 두 가지 암호화 방법을 사용하고 있습니다.

• 대칭키

  암호화 하는 과정에서 key 라는 개념이 필요합니다. 쉽게 이해하자면 암호하는데 필요한 비밀번호와 같은 것입니다. key 값에 따라서 암호화되는 결과가 달라지며 복호화를 위해서도 복호화를 위한 key 가 필요합니다. 대칭키 암호는 암호화를 위한 key 와 복호화를 위한 key 를 같은 것을 사용하는 방식입니다. 이 방법의 문제점은 key 값을 멀리 있는 다른 상대방에게 전달 하는 과정에서 key 값이 노출될 수 있고 이는 보안의 안정성을 깨뜨리게 됩니다.

• 공개키

  공개키 암호는 대칭키 암호의 문제점을 해결할 수 있습니다. 하나의 key 가 아닌, 두 개의 key 를 사용해서 말이죠. 두 개의 key 를 key1, key2 라고 한다면 key1 으로 암호화 하면 key2 로 복호화 할 수 있고, 반대로 key2 로 암호화하면 key1 으로 복호화를 할 수 있습니다. 이 방식이 어떤 장점이 있을까요?

  key1 은 자신만이 가지고 있는 비공개키로, key2 는 타인에게 공개하는 공개키로 사용을 합니다. 공개키를 받은 타인은 자신의 데이터를 공개키를 통해 암호화 할 수 있지만 이를 복호화 할 수 있는 건 비공개키를 가지고 있는 나 자신 뿐 입니다. 이 과정은 key 를 전달할 필요가 없다는 점에서 대칭키 암호의 문제점을 해결하였습니다.

  뿐만 아니라 공개키를 이용해서 인증 도 할 수 있습니다. 비공개키를 가지고 있는 자신이 이를 통해 암호화 해서 보내면 공개키를 가지고 있는 누구나 이를 복호화 할 수 있습니다. 암호로서는 기능이 없는 것과 마찬가지죠. 하지만 공개키로 인증이 되었다면, 이를 통해 내가 보낸 정보라는 것을 인증 받을 수 있는 것 입니다.

 

SSL 인증서의 내용

위에서 봤듯이 인증서를 통해 서버는 클라이언트로 부터의 신뢰를 얻을 수 있습니다. 그 외에도 인증서의 역할은 공개키를 클라이언트에게 제공하는 것 입니다. 왜 제공해야 하는지는 암호화 부분에서 충분히 설명을 드렸다고 생각이 듭니다. 그러면 인증서에는 공개키 말고 또 어떤 내용이 있을까요?

인증서의 내용은 크게 두 가지로 나눌 수 있습니다.

• CA 에 대한 정보

  CA 란 무엇인가요?

  CA 는 Certificate authority 의 약자로 Root Certificate 라고도 하며 영어 그대로 인증기관을 의미합니다. 클라이언트가 접속한 서버가 정상적인 서버가 맞는지 확인하여 맞다면 인증서를 제공해주는 역할을 합니다. 공인된 기업들에서 이 역할을 맡고 있으며 현재 아이덴 트러스트 가 40%, 코모도 가 35% 로 큰 시장 점유율을 차지하고 있습니다. 이러한 CA 로 부터 SSL 인증서를 구매하여야 사용할 수 있습니다.

• 서버와 통신하기 위한 공개키

CA 에 대한 정보는 CA 측에서 제공할 수 있는 것이고, 공개키 같은 경우에는 CA 로 부터 인증서를 구매할 때 제공함으로서 CA 측은 이를 공개키 방식으로 암호화 하게 됩니다. CA 측에서 비공개키를 들고 있고 공개키는 클라이언트가 접근 가능하여 열람할 수 있습니다.

클라이언트는 어떻게 CA 의 공개키를 알 수 있을까요?

클라이언트, 즉 브라우저는 내부적으로 CA 목록을 이미 알고 있으며 각 CA 에 대한 공개키도 알고 있습니다. 브라우저 측에서 믿을 만한 CA 를 선정하고 이들을 미리 등록시켜 놓는 것이죠.

 

naver 의 SSL 인증서

 

SSL 의 동작방법

위에서 알아본 결과, 다음과 같은 결론을 내릴 수 있습니다.

대칭키보다 공개키가 더 좋아보이니까 공개키만을 사용하면 되지 않을까?

하지만 공개키 암호만을 사용한다면 문제가 생깁니다. 바로 공개키 암호는 컴퓨터 자원을 많이 사용한다는 점입니다. 때문에 모든 데이터에 대해서 공개키 암호만을 사용한다면 컴퓨팅 자원에 손해가 생길 것입니다. 때문에 두 가지 방법을 혼용해서 사용합니다. 실제 데이터에 대해서는 대칭키 암호로 암호화를 하고, 대칭키 암호의 key 를 공개키 암호로 암호화 하게 됩니다.

이를 자세히 이해하기 위해서는 악수 에 대해서 알아야 합니다.

• 악수

  handshake 라고도 하며 사람과 사람이 처음 만나 악수를 하듯이 컴퓨터 세계에서도 클라이언트와 서버가 처음 만나 악수 하는 것과 같다하여 이름 붙였습니다. 클라이언트와 서버가 서로에 대해 파악하는 단계입니다.

  handshake 과정

  1. Client Hello

     이 과정은 클라이언트가 서버에 접속하는 것을 말합니다. 클라이언트에서 생성한 랜덤 데이터와 암호화 방식을 서버에 넘겨줍니다. 랜덤 데이터가 무엇인지는 뒤에서 자세히 다룰 것이고, 암호화 방식은 서버와 클라이언트가 차이가 있을 수 있기 때문에 조율을 위해서 클라이언트가 가능한 암호화 방식을 서버로 넘겨주는 것 입니다.

  2. Server Hello

     이 과정은 클라이언트의 Client Hello 에 대한 서버의 응답입니다. 서버에서 생성한 랜덤 데이터 와 결정된 암호화 방식 , 그리고 인증서 를 클라이언트에 넘겨줍니다. Client Hello 에서 받았던 클라이언트가 가능한 암호화 방식 중에서 서버가 적잘한 방식을 골라 결정하게 됩니다.

  3. 인증서 확인 클라이언트는 Server Hello 로 부터 인증서를 받은 후, 확인을 합니다. 인증서를 발급한 인증기관 , CA 가 브라우저의 CA 목록에 있는지 확인해보고 없다면 사용자에게 경고메세지를, 있다면 브라우저에 내장되어 있는 CA 의 공개키를 통해 인증서를 복호화 합니다. 성공한다면 이는 클라이언트가 원하는 서버에서 보낸 인증서가 확실하므로 서버를 보증하게 됩니다.

  4. 대칭키 암호의 키 생성 Client Hello , Server Hello 과정에서 클라이언트와 서버는 랜덤한 데이터를 생성하였습니다. 클라이언트는 인증서를 확인했다면, 이 두 데이터를 통해 pre master secret 이라는 키를 생성합니다. 이는 후에 클라이언트에서 서버로 보낼 내용을 암호화할 대칭키 암호의 키의 근본이 됩니다. 이 키를 서버의 공개키를 통해서 암호화하여 서버로 전송하게 됩니다.

  5. 서버의 데이터 복호화 서버는 비공개키를 통해 pre master secret 을 복호화 하고 합니다. 서버와 클라이언트는 pre master secret 을 공유하게 되고 이를 통해 master secret 을 생성, 다시 master secret 으로 session key 를 생성합니다. 이 키는 후에 서버와 클라이언트 사이에 데이터를 주고 받을 시 암호화할 대칭키 암호의 키가 됩니다. 이로서 handshake 가 종료됩니다. session key 는 데이터 전송이 끝나고 통신이 종료되면 폐기합니다.

 

SSL 인증서 선택하기

위에서도 몇 번 언급했지만 SSL 인증서를 발급 할 수 있는 인증기관은 여러 곳이 있습니다. 전세계와 국내의 CA 점유율은 다음과 같습니다.

전세계 CA 기업 시장 점유율 ( 2018년 5월 W3Techs 설문조사 )

Rank	Issuer	Market share
1	IdenTrust	39.7%
2	Comodo	34.9%
3	DigiCert	12.3%
4	GoDaddy	7.2%
5	GlobalSign	3.5%
6	Certum	0.7%
7	Actalis	0.3%
8	Entrust	0.3%
9	Secom	0.3%
10	Let's Encrypt	0.2%

국내 CA 기업 시장 점유율 (2018년 2월 Netcraft)

Rank	Issuer	Market share
1	DigiCert	39.7%
2	Comodo	34.9%
3	Other	12.3%
4	GlobalSign	7.2%

이 외에도 무수히 많은 국내외 CA 기업들이 존재합니다. 각 기업마다 인증서의 가격도 천차만별이고 심지어 무료인 기업도 존재합니다. 상식적으로 유료 인증서가 무료 인증서보다 더 좋을 것이라는 예상이 되지만 유료 인증서와 무료 인증서 간의 성능은 큰 차이가 없습니다. 유료인증서들 끼리도 가격에 따른 성능차이는 존재하지 않습니다. 차이라고 한다면 사이트가 해킹 당했을 때, 그에 따른 배상시스템 정도이고 이는 유료인증서를 사용하였을 경우 배상 받을 금액이 훨씬 높습니다.

결과적으로 개인이나 비영리, 혹은 소규모에 대해서는 무료 SSL 인증서를 사용해도 별 문제 없습니다.

 

EV, OV, DV 인증서

인증서도 여러 종류로 나뉘게 됩니다. 인증서의 동작 방식은 위에서 살펴본 것과 같이 모두 비슷하지만 CA 에서 인증서를 발행하기 까지 얼마나 확인하는지 여부에 따라서 나뉘게 됩니다.

• DV

  Domain Validation 의 약자이며 도메인 소유/관리 권한에 대한 간단한 DCV 검사만 확인 후 발급되는 인증서 입니다. 저렴한 가격이며, 서류 제출 필요 없이, 인증기관 CA에서 규정한 Email/DNS/HTTP 인증 방법만 통과하면 발급이 완료됩니다. 발급 소요시간은 2~5분 사이 완료됩니다.

• OV

  Organization Validation 의 약자이며 도메인 소유/관리 권한 DCV 검사 뿐만 아니라 해당 인증서를 신청한 기관에 대한 실체 여부까지 확인후 발급되는 인증서 입니다. DV 보다는 비교적 상품 가격이 높으며, 인증기관 CA 의 서류심사 및 전화인증을 필수로 거쳐야 합니다. 발급 소요시간은 보통 3일~7일 정도 소요가 됩니다. 꽤 많은 서류가 필요하며 서류가 미비할 경우 발급이 불가능합니다.

• EV

  Extended Validation 의 약자이며 가장 높은 인증 수준을 나타냅니다. 그 만큼 발급받기 까다롭습니다. 사업자등록증으로 도메인을 사용하는 소유주와 사업자등록증 상의 업체가 일치하는지 확인하고, 전화통화를 통해서 신청자가 사업장에 재직중임을 확인하고 마지막으로 담당자와 통화하여 인증서를 구매한 것이 맞는지 확인합니다. 당연히 DV 와 OV 의 인증 절차까지 모두 거칩니다. 주소창이 녹색으로 변해 방문자들에게 안전한 사이트 임을 시각적으로도 나타낼 수 있습니다. 금융사이트나 관공서 등에서 사용하곤 합니다.

 

SSL 인증서 상세보기를 했을때 상세 정보에 회사, 기업의 정보가 표기 되어야 하는 특별한 이유가 있으면 OV인증서나 EV 인증서를 선택하는 것이 옳습니다. 그렇지 않으면 불필요한 비용 지불과 절차를 수행할 필요가 없는 DV 인증서를 선택하는 것이 합리적 입니다.