개요
인프라팀에서 근무하며 서비스의 모든 도메인과 SSL 인증서 관리를 진행했었는데, 구매부터 발급, 갱신, 적용 과정을 직접 진행했던 기억이 난다.
작업했던 시스템 별 인증서 적용 방식의 차이(Nginx, Tomcat 등 서버, AWS, NCP 등 클라우드 서비스 등)와 인증서 종류(단일, 와일드카드 등 인증서 유형부터 EV,OV,DV 등 인증서 등급까지)등 내가 경험했던 내용에 대입하여 SSL 인증서의 기본적은 개념과 원리를 한번 되짚어 보려 한다.
1. SSL이란?
SSL(Secure Sockets Layer)은 암호화 기반 인터넷 보안 프로토콜이다. 인터넷 통신의 개인정보 보호, 인증, 데이터 무결성을 보장하기 위해 Netscape가 1995년 처음으로 개발하였다.
- SSL은 현재 사용중인 TLS 암호화의 전신이다.
보통 SSL과 TLS를 동일하게 부르며, TLS 1.0은 SSL 3.0을 계승한다.
즉, SSL의 새로운 버전이 TLS이다. (그래서 SSL/TLS로 묶어서 부르기도 한다.)
* 더 상세히 설명하자면 Netscape에서 SSL이 개발되었고, SSL이 폭넓게 사용되다 표준화 기구인 IETF의 관리로 변경되면서 TLS이라는 이름으로 변경된것이다.
1.1 SSL/TLS 작동 원리
다음 4. 암호화 작동 원리 항목에서 상세히 다뤄보겠지만, SSL 개념을 살펴보며 원리를 간단히 확인해보겠다.
- SSL/TLS은 웹에서 전송되는 데이터를 암호화한다. 즉, 중간에 데이터를 가로채는 대상은 해독하기 힘든 암호화된 문자열만 보게 된다.
- SSL/TLS은 서버와 클라이언트 통신 사이에 핸드세이크라는 인증 프로세스를 시작하며 두 대상의 ID를 확인한다.
- 또한 데이터 무결성을 제공하기 위해 데이터에 디지털 서명을 진행하며 수신자에게 도착하기 이전에 조작되지 않았다는 것을 확인한다.
원래 웹 상의 데이터는 중간에 가로채면 누구나 읽을 수 있는 일반적인 텍스트 형태로 전송되었다.
즉, 사용자가 쇼핑 웹사이트에서 신용 카드 정보를 입력한다면 이 정보가 숨겨지지 않은채 인터넷을 이동하게 된다.
SSL은 이런 개인 정보를 보호하기 위해 개발되었다. 사용자와 웹 서버 사이를 이동하는 모든 데이터를 암호화하여, 누군가 데이터를 가로채더라도 무작위 문자열만 볼 수 있게 만든다.
2. SSL 인증서란?
SSL 인증서란 쉽게 클라이언트와 서버간의 통신을 제 3자가 보증해주는 문서라고 생각하면 된다.
SSL은 SSL 인증서(물론 공식적으로는 TLS 인증서이다.)가 있는 웹사이트에서만 실행될 수 있다. 웹사이트나 애플리케이션 서버가 SSL 인증서를 웹에 저장하고 표시하며 CA(인증 기관)에서 SSL 인증서 발행을 담당한다.
SSL 인증서는 단일 데이터 파일에 다음 정보를 포함시킨다.
- 인증서가 발듭된 대상 도메인 이름
- 발급 받은 사람, 조직, 장치
- 발급한 인증 기관
- 인증 기관의 디지털 서명
- 관련된 하위 도메인
- 인증서 발급 날짜
- 인증서 만료 날짜
- 공개 키(개인 키는 비밀로 유지된다)
인증서는 원본 서버에서 호스팅되며, 웹사이트 로드를 요청하든 모든 시스템에 전송된다.
2.1 SSL 인증서 유형
SSL 인증서는 다양한 유형이 있다. 하나의 도메인만 적용되는지, 여러 도메인에 적용되는지에 따라 유형이 달라진다.
| 단일 도메인 | 단일 도메인 SSL 인증서는 단 하나의 도메인 (여기서 도메인은 웹사이트에 적용되는 서브도메인을 말한다.) ex, www.cwdev.site)에 적용된다. |
| 와일드카드 | 와일드카드 SSL 인증서는 Root 도메인에 적용된다. 즉, 서브 도메인을 모두 포함한다. ex, *.cwdev.site로 발급받으면, www.cwdev.site, resume.cwdev.site, api.cwdev.site 등 여러 도메인에 적용 가능하다.
|
| 멀티 도메인 | 이름에서 유추할 수 있는데, 멀티 도메인 SSL 인증서는 다수의 Root 도메인에 적용할 수 있다. ex, www.devcw.site www.cwking.com, www.devops.cwpack 등…
|
2.2 SSL 인증서 등급
SSL 인증서가 적용되는 여러 대상에 대한 유형이 존재하듯, SSL 인증서의 인증 등급에 따른 분류도 존재한다. 즉, SSL 인증서마다 유효성 검사 수준이 차이가 난다.
- DV(Domain Validation) 도메인 유효성 검사
- 도메인 소유 검증 절차만 있다. 가장 간단하며 약 5분정도 소요되는 것 같다. 누구나 발급이 가능하다.
- 인증서 분류 중 가장 덜 엄격하다. 도메인을 관리하고 있다는 것만 확인한다.
- OV(Organization Validation) 조직 유효성 검사
- 도메인 소유 검증 절차와 조직(회사) 검증 절차가 존재한다. 길면 2~3일 정도 소요된다.
- 실제로 신청한 회사로 인증업체에서 연락이 온다. 내 경우 우리 회사의 재무팀, 경영팀에 전화가 오고, 회사의 주소명과 신청자(나)가 해당 직장에 재직중인지를 확인한다.
- 좀 더 실무적인 프로세스이다. CA가 담당자나 기업에 인증서를 직접 문의한다.
- EV(Extended Validation) 확장 유효성 검사
- 도메인 소유 검증 절차와 조직에 대해 구체적인 검증 절차로 진행된다. 최대 3주정도 소요된다고 한다.
- 일반적으로 금융권이나 공공기관에서 사용하며, 브라우저에 따라 녹색 창이 나오는 등 차별화가 있다.
- 조직의 배경을 완전히 검사한 후에 SSL 인증서를 발급한다.
2.3 자체 서명 SSL 인증서
물론 CA이 아니더라도 기술적으로 누구나 공개-개인 키 페어링을 생성하여 자신만의 SSL 인증서를 만들 수 있다. 이 경우를 자체 서명 인증서라고 부른다.
하지만 자체 서명 인증서를 사용하게 되면 원본 서버가 자신이 주장하는 서버인지 확인할 수 있는 외부 기관(제 3자)이 없다. 그렇기 때문에 브라우저에서는 자체 서명된 인증서를 신뢰할 수 있는 것으로 간주하지 않는다.
즉, 자체 서명 인증서가 있는 사이트는 https://로 접근함에도 불구하고 “안전하지 않음”으로 표시된다.
자체 서명 인증서는 OpenSSL, 자바의 keytool, 어도비 리더, WolfSSL 및 애플의 키체인 및 등 다양한 도구를 사용하여 무료로 발급할 수 있다.
3. HTTP vs HTTPS
HTTPS는 암호화 인증이 포함된 HTTP이다. 즉 두 프로토콜의 유일한 차이점은 HTTPS의 경우 SSL/TLS을 사용하여 HTTP 요청과 응답을 암호화하고 디지털 서명을 한다는 점이다.
HTTPS는 HTTP보다 더욱 안전하며 HTTP를 사용하는 웹 사이트의 URL은 http://, HTTPS를 사용하는 웹 사이트는 https://로 표시된다.
HTTP란?
HTTP는 하이퍼텍스트 전송 프로토콜의 약자로, 네트워크를 통해 데이터를 전송하는데 사용되는 프로토콜 혹은, 정보를 표현하기 위한 규정된 순서와 구문을 뜻한다.
(웹 사이트 컨텐츠 및 API 호출 등 인터넷을 통해 전송되는 대부분의 정보는 HTTP 프로토콜을 사용한다.)
정리하자면 다음과 같다.
- HTTP와 HTTPS는 엄밀히 보면 별개의 프로토콜이 아니다. HTTPS는 단순히 HTTP 프로토콜을 SSL/TSL을 통해 암호화로 사용하는 것이다.
- HTTP는 80 포트를 사용하며 HTTPS는 443 포트를 사용한다.
4. 암호화 작동 원리
IT의 보안 인증 방식은 대부분 키를 어떻게 관리하며 대칭/비대층을 조합, 비교하며 사용할 것인가에 따라 발전해왔다. 즉, SSL 인증의 보안 방식도 키를 이용한 암호화를 통해 신뢰성을 파악한다.
물론, 보안 방식이 키를 어떻게 대칭시키느냐 뿐만이 아니라 다양한 신뢰 모델과 인증 방식등이 존재한다. 이에 대해서는 따로 IT의 보안 인증 방식에 대해 글을 작성해보겠다.
4.1 암호화란?
암호화는 승인된 당사자만 볼 수 있도록 데이터를 변환시키는 방법이다. 일반적인 텍스트를 사람이 이해할 수 없는 텍스트로 변환하는 과정으로, 암호 텍스트라고도 불린다.
암호화를 사용하려면 *암호화 키를 사용해야 한다.
*암호화된 메세지의 발신자와 수신자가 모두 동의하는 수학적 값 집합
4.2 암호화 동작 방식
암호화는 암호화 알고리즘과 키를 사용하여 데이터를 변경하는 수학적인 프로세스이다.
예를 들어 A가 B에게 “Hello”라는 메세지를 보내며 각 문자를 알파벳 순서에서 두 자리 뒤에 오는 문자로 바꾼다고 가정해보겠다. “Hello” 대신 “Jgnnq”라고 보내지나, B는 다행이도 “2”라는 Key를 알고 있고, 메세지를 다시 “Hello”로 해독할 수 있다.
물론 이는 매우 간단한 암호화 알고리즘이다. 실제로는 더 복잡한 암호화 알고리즘을 사용한다.
즉, 암호화된 데이터는 무작위로 보이지만, 사실 논리적이고 예측 가능한 방식으로 진행되므로 올바른 키를 가지고 있다면 데이터를 다시 해독하여 변환할 수 있는 것이다.
최근의 암호화 방식은 제 3자가 무차별 대입으로 암호문을 해독할 가능성이 거의 없을 정도로 엄청나게 복잡한 키를 사용한다.
4.3 암호화의 유형
암호화에는 대칭 암호화와 비대칭 암호화 두 가지 주요 유형이 있다.(비대칭 암호화는 공개키 암호화라고도 한다.)
- 대칭 암호화: 대칭 암호화 방식은 동일한 키로 암호화와 복호화를 할 수 있는 기법을 뜻한다. 즉, 하나의 키로 모든 통신 당사자들은 암호화와 해독 모두 가능하도록 사용한다.
- 비대칭 암호화: 비대칭(공개키) 암호화 방식은 대칭키 방식과 다르게 2개의 키를 가지고 진행한다. 하나의 키는 암호화에 사용되고, 다른 키는 해독에 사용된다. 해독 키는 개인키라고도 불리며, 비공개로 유지되고, 암호화 키는 누구나 사용할 수 있도록 공개적으로 공유되어 공개키라고도 불린다.
SSL/TLS는 공개 키 암호화라는 기술을 사용한다. 공개 키는 서버의 SSL 인증서를 통해 클라이언트 장치와 공유되며 클라이언트가 서버와의 연결을 열면 두 장치는 공개 키와 개인 키를 사용하여 세션 키라는 새 키에 동의하여 두 장치 간의 추가 통신을 암호화한다.
모든 HTTP 요청과 응답이 이 세션 키로 암호화되므로 통신을 가로채는 사람은 일반 텍스트가 아닌 임의의 문자 문자열만 볼 수 있다.
4.4 암호화 알고리즘과 무차별 대입 공격
일반적으로 사용되는 대칭 암호화 알고리즘은 다음과 같다.
- AES
- 3-DES
- SNOW
일반적으로 사용되는 비대칭 암호화 알고리즘은 다음과 같다.
- RSA
- 타원 곡선 암호
무차별 대입 공격
무차별 대입 공격은 해독 키를 모르는 공격자가 수백 ~ 수십억 번의 추측을 통해 키를 알아내려고 시도하는 것이다. 최신 컴퓨터는 암호 대입 공격이 훨씬 빠르므로 암호화 또한 복잡해져야 한다.
최근의 암호화 기법은 비밀번호와 결합되어 무차별 대입 공격에 어느정도 저항력이 있지만, 컴퓨터가 점점 발전함에 따라서 이런 공격에 취약해질 수 있다.
4.5 HTTP 요청 암호화 예시
앞서 설명했듯, HTTPS는 SSL/TLS를 사용하여 HTTP 요청과 응답을 암호화하므로 공격자는 텍스트 대신 무작위로 보이는 문자를 보게 된다.
예를 들어 다음 HTTP 요청을 진행한다 가정했을때 일반적인 HTTP 응답은 다음과 같다.
HTTP 요청 예시
GET /hello.txt HTTP/1.1
User-Agent: curl/7.63.0 libcurl/7.63.0 OpenSSL/1.1.l zlib/1.2.11
Host: www.example.com
Accept-Language: en
HTTP 응답 예시
HTTP/1.1 200 OK
Date: Wed, 30 Jan 2019 12:14:39 GMT
Server: Apache
Last-Modified: Mon, 28 Jan 2019 11:17:01 GMT
Accept-Ranges: bytes
Content-Length: 12
Vary: Accept-Encoding
Content-Type: text/plain
Hello World!
그러나 HTTPS로 암호화한다면, 공격자는 다음과 같은 응답을 받게된다.
HTTPS 응답 예시
t8Fw6T8UV81pQfyhDkhebbz7+oiwldr1j2gHBB3L3RFTRsQCpaSnSBZ78Vme+DpDVJPvZdZUZHpzbbcqmSW1+3xXGsERHg9YDmpYk0VVDiRvw1H5miNieJeJ/FNUjgH0BmVRWII6+T4MnDwmCMZUI/orxP3HGwYCSIvyzS3MpmmSe4iaWKCOHQ==
5. 마치며
이번 글을 작성하며 저도 SSL의 작동 원리, 인증서의 개념과 종류, 그리고 HTTP와 HTTPS의 차이, 암호화의 원리 까지 하니씩 다시 되짚어보는 시간을 가지게 되었습니다.
사실 인터넷에서 우리가 주고받는 많은 데이터는 보이지 않는 곳에서 계속해서 보호받고 있습니다. 브라우저에 표시되는 작은 자물쇠 아이콘 하나가 단순한 UI 요소가 아니라 사이트간 신뢰와 보안을 나타내는 정말 중요한 장치라는 점을 느끼게 되었습니다.
현재 IT 공격 방식은 나날히 발전하고 있습니다. 이에 맞춰 보안도 개선되고 있지만, 결국 보안의 기본을 이해하고 실천하는 것이 무엇보다 중요하다고 생각합니다. IT를 다루는 엔지니어라면, 언제나 경각심을 가지고 학습해야 한다는 생각이 드는 시간이였습니다.
읽어주셔서 감사합니다.(_ _) 꾸벅
+ 여담. SSL 인증서 발급 후 DNS 정보가 변경된다면?
가비아를 통해 구입한 도메인을 AWS Route53에 등록하여 사용하고 있었는데, 이때 AWS Route53에 TXT 레코드를 추가하여 SSL 인증서를 발급받았었다.
이떄 AWS → NCP로 마이그레이션을 진행하며 도메인 관리도 Route53 → NCP GlobalDNS로 변경하는 작업을 진행하였는데,
문득 궁금해졌다. DNS 관리 정보가 변경되면 SSL 인증서도 재발급이 필요할까?
SSL 인증서 발급 원리
Q: Route53에서 TXT 레코드를 추가하여 SSL 인증서를 발급받은 후, DNS를 다른 서비스로 이전해도 인증서를 계속 사용할 수 있을까?
A: 결론적으로 사용할 수 있다.
본인의 경우 DV유형의 SSL 인증서로 도메인 소유권을 확인한 후 발급하는 형식인데, 도메인 레코드 설정에서 SSL 인증 기관이 지정해준 TXT 레코드를 추가하여 발급받게 된다.
이때, TXT 레코드는 발급 과정에서만 필요하며, 발급 후에는 인증서 자체에 영향을 주지 않는다.
그리고 DNS 서비스를 이전한다 하더라도, SSL 인증서는 DNS 레코드와 무관하며 웹 서버에서 사용되는 인증서이기 때문에 도메인 이름이 동일하고 SSL 인증서가 잘 설정되어 있다면 문제가 없다.
즉, 도메인 소유권은 인증서 발급 당시에만 존재하면 되고, DNS를 다른 서비스로 이전해도 기존 SSL 인증서는 유효하다.
>. 발급 당시의 소유권만 확인한다면, 생각보다 보안적으로 안전하지 않을 수 있다는 생각이 든다.
그래서 조사를 해봤는데, 보안을 이유로 google은 인증서의 갱신 기간을 90일, apple은 47일로 단축하는 제안을 했다고 한다
링크^^
웹사이트 인증서가 6주마다 만료되면?··· 기업 IT를 위한 가이드북
웹사이트 인증서 업데이트 주기를 대폭 단축하라고 요구하는 움직임이 거세지고 있다. 주로 애플과 구글이 주도하는 이 움직임이 내세우는 명분은 ‘보안’이다. 그러나 이 움직임과 명분에 대
www.cio.com
물론 공식적인 단축 이유는 방치된 도메인 이름을 활용한 피싱, 도용 등을 방지하기 위함이나, 인증 기간을 자주 진행함으로서 도메인 소유권 확인도 더욱 정확해 질 것 같다는 생각이 들었다.
참고자료
https://www.cloudflare.com/ko-kr/learning/ssl/what-is-an-ssl-certificate/
https://aws.amazon.com/ko/what-is/ssl-certificate/
https://nordvpn.com/ko/blog/what-is-ssl-certificate/
https://computing-jhson.tistory.com/117#google_vignette
https://it-sunny-333.tistory.com/144
'DevOps > Network_네트워크' 카테고리의 다른 글
| DNS의 동작 원리 및 구성 방법(레코드 종류와 root 도메인) (1) | 2025.01.26 |
|---|---|
| [OpenVPN] OpenVPN Server 구축(Linux) (0) | 2024.11.17 |
| [VPN] FortiGate(Fortinet) SSL-VPN 설정 (0) | 2023.07.18 |
| [NetWork] IPSEC VPN 개념과 2가지 모드 (0) | 2023.07.18 |
| [NetWork] SSL VPN 개념과 유형 (0) | 2023.07.17 |
