SSL (Secure Sockets Layer) / TLS (Transport Layer Security)

https://hwanii96.tistory.com/536

HTTP vs HTTPS [2] & SSL

 

HTTPS의 S는 Secure의 약어로, 기존 HTTP 프로토콜에서 Secure Layer가 추가된 프로토콜이다.

 

HTTPS의 Secure Layer는 SSL (Secure Sockets Layer) / TLS (Transport Layer Security) 가 사용 된다.

 

SSL은 보안 소켓 계층 이라 하며,

양쪽에서 HTTPS 방식으로 데이터를 주고 받을 때, 안전하게 암호화된 연결을 할 수 있도록 도와주는 역할을 한다.

 

위의 글에서도 HTTPS에 대해 학습 하면서 SSL도 같이 학습 했지만, 이 게시글에서 더 다뤄보려고 한다.

 

---

[ Index ]

 

1. SSL / TLS 인증서 개념

 

1) SSL과 TLS 이란 ?

2) SSL vs TLS 주요 차이점

3) SSL 프로토콜의 구조

4) SSL 디지털 인증서란 ?

5) SSL 인증서를 이용 하는 이유

6) SSL에서 사용 하는 암호화의 종류

7) SSL 인증서를 만들어 주는 인증 기관 (CA == Certificate Authority)

* Certificate : 증명서 / 자격증 / 자격

* Authority : 권한 / 인가

* Certificate Authority : CA : 자격 증명 권한 부여 == 인증 기관

 

2. SSL / TLS 인증서 내용

 

1) SSL 인증서의 내용

2) SSL 인증서의 구조

3) SSL 개인 인증서를 신뢰할 수 없다면 ?

 

3. SSL / TLS 인증서 작동 원리

 

1) SSL 인증서 보안 연결 수립 Process

 

4. SSL / TLS 인증서 종류

 

1) 발급 기관에 따른 SSL 인증서 종류

2) 심사 수준에 따른 SSL 인증서 종류

3) 도메인에 따른 SSL 인증서 종류

4) 인증서 포맷에 따른 SSL 인증서 종류

 

5. ISVA 내부 SSL 인증서 관리

 

1) ISVA (IBM Security Verify Access) 기본 SSL Certificates Database 종류

2) 사설 인증서 생성 방법

3) Tomcat 사설 인증서 생성 및 ISVA 내부 SSL 인증서 등록 방법

 

---

 

1. SSL / TLS 인증서 개념

 

1) SSL과 TLS 이란 ?

 

내용 : SSL/TLS 

 

 

 

SSL (Secure Sockets Layer) 과 TLS (Transport Layer Security) 는 같은 개념으로 봐도 무방 하다.

* Transport : 수송, 이동 / 수송 하다, 이동 하다

 

Netscape Communications라는 회사에서 WWW (World Wide Web)의 통신을 안전 하게 유지 하는 것을

목적으로 SSL (Secure Sockets Layer) 이 개발 되었다.

처음에는 SSL이 폭넓게 사용되다가, 표준화 기구인 IETF의 관리로 변경 되어 TLS라는 이름으로 변경 되었다.

 

TLS 1.0 Ver은 SSL 3.0 Ver을 계승 한다.

SSL은 보안의 문제가 많아서 현재는 모든 버전의 SSL은 더 이상 사용 되지 않는다.

따라서, 현재는 TLS를 사용 하고 있지만, 현실에서는 TLS를 SSL로 부르면서 사용 하고 있다.

 

2) SSL vs TLS 주요 차이점

 

 

참고 : MAC (Message Authentication Code)

 

 

MAC (Message Authentication Code) 는 SSL에서 사용 되었던 메세지의 무결성을 보호 하기 위한

작은 고유의 코드 블록을 의미 한다.

 

여기서의 메세지란 클라이언트와 서버간의 송수신되는 모든 데이터를 의미 한다.

 

MAC은 대칭키 알고리즘을 사용 해서 생성 된다.

 

현재는, SSL 대신에 TLS를 사용 하기 때문에, 마찬가지로 MAC 대신에 HMAC이 사용 되고 있다.

HMAC은 안전한 키 관리 및 해시 함수의 안전성을 결합 해서 강력한 보안을 제공하는 MAC의 한 종류 이다.

 

HMAC은 TLS (Transport Layer Security) 또는 OAuth (Open Authorization) 등 다양한 보안 프로토콜에서 사용 된다.

 

참고 2 : MAC (Message Authentication Code)

 

 

MAC : Message Authentication Code

 

개요 :

MAC은 메세지 (== 데이터) 의 무결성을 보호 하기 위한 작은 고유의 코드 블록 이다.

대칭키 알고리즘을 사용 해서 생성 된다.

 

사용 목적 :

메세지 (== 데이터) 가 전송되거나 저장될 때, MAC은 메세지가 변경 되지 않았음을 확인 하기 위해서 사용 된다.

== 메세지의 무결성

 

알고리즘 :

대칭 키 블록 암호화 알고리즘이 MAC 생성에 사용 된다.

 

동작 방식 : 

 

클라이언트는 데이터 (== 메세지) 와 공유된 대칭 키를 사용 해서 MAC을 생성 하고, MAC을 데이터에 추가 한다.

서버는 클라이언트가 보내준 MAC이 포함된 데이터를 받고, 동일한 대칭 키를 사용 한다.

이때, 서버가 받은 데이터 에서도 MAC을 생성 하고, 클라이언트가 생성한 MAC과 비교 해서 무결성을 확인 한다.

 

부가 설명 :

 

클라이언트가 서버에게 데이터를 보내는 상황이라고 가정.

클라이언트의 대칭 키를 서버에게 안전하게 전달 하기 위한 과정을 끝내고, 서버 에게 대칭 키를 전달 했을 때,

 

MAC은 클라이언트의 대칭 키를 사용 해서 데이터를 서명 한다.

그리고, 서버는 동일한 대칭 키를 사용 해서 MAC을 생성 하고, 클라이언트가 보낸 데이터의 서명을 확인 한다.

 

만약에 클라이언트가 보낸 데이터가 중간에 변경 되었으면,

서버에서 받은 데이터를 대칭 키로 복호화 하는 과정 에서 MAC이 일치 하지 않게 되서,

데이터 무결성 검사에 실패 하게 된다.

 

왜냐하면, 같은 대칭 키로 MAC을 생성 하면, 데이터에 항상 같은 서명 (MAC 값) 이 생성 된다.

MAC은 동일한 입력에 대해 항상 동일한 출력을 생성 하는 불변성을 가지고 있기 때문 이다.

 

Hash-Based Message Authentication Code (HMAC)

 

개요 :

HMAC은 MAC의 한 종류 이다.

단어 그대로, 해시 함수를 기반으로 하는 메세지 (== 데이터) 인증 코드 이다.

 

오늘날에는 SSL (Secure Sockets Layer) 대신에 TLS (Transport Layer Security) 를 사용 하기 때문에,

대표적으로 사용 되고 있는 MAC 중 하나 라고 할 수 있다.

 

알고리즘 :

표준적으로는 해시 함수와 대칭 키 알고리즘을 결합 해서 사용 된다.

기존의 MAC은 대칭 키 알고리즘만을 활용 해서 생성 했다면, HMAC은 해시 함수가 추가된 것이다.

 

주로, MD5, SHA-256, SHA-3 등의 해시 함수를 사용 한다.

 

동작 방식 :

1) 클라이언트는 데이터 + 대칭 키를 결합 하고, 해시 함수에 입력 한다.

2) 해시 함수를 통해서 생성된 해시 값 + 대칭 키를 다시 해시 함수에 입력 해서 최종적인 HMAC을 생성 한다.

3) 서버는 동일한 대칭 키를 사용 해서, 클라이언트가 보낸 데이터의 HMAC을 생성 하고 무결성을 확인 한다.

 

참고 :

 

MD5 : Message Digest Algorithm 5

MD5는 128 비트 (16 바이트) 의 해시 값을 생성 하는 알고리즘 이다.

현재는 보안이 취약해서 사용 되고 있지 않다.

 

SHA-256 : Secure Hash Algorithm 256-bit 

SHA-256은 256 비트 (32 바이트) 의 해시 값을 생성 하는 SHA-2 계열의 알고리즘 중 하나 이다.

현재 가장 안전한 해시 함수로 여겨져, 많이 사용 되고 있다.

 

SHA-3 : Secure Hash Algorithm 3 

SHA-3은 2015년에 NIST에 의해 표준으로 제정된 해시 함수 이다.

SHA-3은 SHA-2와 다른 구조를 가진다.

최근에 만들어졌기 때문에 안전한 해시 함수 이다.

하지만, 아직까지는 SHA-2 기반의 알고리즘이 가장 많이 사용 되고 있다.

 

3) SSL 프로토콜의 구조

 

내용 1 : SSL 프로토콜 구조

 

 

SSL 프로토콜의 구조

 

SSL Record Protocol :

상호 송/수신을 위한 암호화 Cipher Suite가 SSL / TLS HandShake 프로토콜에 의해 정해지고,

Cipher Suite에 따라 실제로 전송 되는 데이터를 TCP 패킷으로 변환 하기 위한 기능을 수행 하는 프로토콜 이다.

 

즉, 데이터를 TCP 패킷으로 변환 하는 놈 이라고 생각 하면 된다.

 

SSL Change Cipher Spec : 

서버 측 (받는 측 == 수신 측) 의 Cipher Suite에서, 

여러 목적의 알고리즘, 여러 종류의 키, 압축 방식 등을 알려주는 용도로 사용 된다.

 

SSL Alert Protocol :

SSL (Secure Sockets Layer) 의 동작 과정에서 발생할 수 있는 문제에 대해 경고를 전달 하기 위해 사용 된다.

 

Cipher Suite :

 

* Cipher : 암호

* Suite : 세트 (가구 등의 한 세트) / 모음곡 / 수트 (정장)

 

Cipher Suite는 네트워크 통신에서 암호화 및 인증 알고리즘의 조합을 나타내는 용어 이다.

한마디로, 통신 보안을 정의 하는 것 이라고 생각 하면 된다.

주로 TLS 및 SSL 프로토콜에서 사용 된다.

 

Cipher Suite를 통해 클라이언트와 서버 간의 통신에서 어떤 암호 알고리즘 및 키 교환 방법이 사용 되는지를 정의.

 

Cipher Suite에는 여러 정의 요소가 있지만, 일반적으로는 다음과 같다.

 

1) 키 교환 알고리즘 

클라이언트와 서버 간의 키를 어떻게 안전하게 교환할건지 방법을 정의.

 

2) 인증 알고리즘

클라이언트와 서버 간의 교환한 인증서를 확인 하는 알고리즘을 정의.

(신원을 확인하는 데 사용 되는 알고리즘)

 

3) 대칭 암호 알고리즘

실제 데이터를 암호화 및 복호화 하는데 사용 되는 키 알고리즘을 지정.

 

4) 블록 암호 운용 방식

데이터를 암호화 할 때, 전체를 한 번에 암호화 하지 않음을 의미.

데이터는 블록 단위로 암호화를 진행 한다.

블록 단위로 암호화된 패킷을 조합해서, 원본 데이터를 얻는 것을 방지.

 

5) 해시 알고리즘

서로 상대방이 암호화한 데이터가 정말로 맞는지 (데이터 무결성) 를 확인 하기 위한 알고리즘을 정의.

(데이터의 무결성을 검증할 때, 양쪽에서 데이터로부터 HMAC을 생성 해서 확인 한다고 했다)

 

예시)

 

네트워크의 패킷을 캡쳐할 수 있는 소프트웨어인 Wireshark를 사용 해서 Cipher Suite를 확인할 수 있다.

 

 

 

[ 해석 ]

 

TLS (Transport Layer Security) 프로토콜을 사용 하고,

키 교환 방식으로 ECDHE 방식을 사용 하고,

인증 알고리즘으로 RSA,

대칭 암호 알고리즘으로 AES을 사용 하고, 이 암호의 길이를 256 bit로,

블록 암호 운용 방식으로는 GCM,

HMAC의 해시 알고리즘으로는 SHA-384를 사용한다는 의미가 된다.

 

내용 2 : OSI 7 계층 기본 개념

 

 

OSI (Open Systems Interconnection) 7 계층에서, 각 계층은 역할이 존재 한다.

각 계층은 데이터를 받아서 자신의 역할에 맞게 데이터를 처리한 후, 다음 계층으로 전달 한다.

이때, 역할에 따라 데이터는 상위 계층에서 하위 계층으로 전달 된다.

 

HTTP (S) 는 응용 계층으로 최상위 계층 (7 계층) 이다.

 

TCP / IP 계층은 전송 계층으로, OSI 7 계층에서 네 번째인 4 계층에 속한다.

 

가장 최전방의 계층인 응용 계층에 속하는 프로토콜 (HTTP, ..) 등은 사용자의 데이터 통신을 처리 한다.

 

즉, 이 계층에 위치한 프로토콜은 사용자와 직접적인 상호 작용을 하는 계층이라는 것을 의미 한다.

 

참고 :

 

"HTTP는 TCP/IP 계층 위에 있다" 라고 표현 되는데, 이 말은 다음과 같다.

 

HTTP는 최상위 계층인 응용 계층에서 동작 하기 때문에, 실제 데이터의 전송은 전송 계층에서 담당 된다.

따라서, 역할에 따른 계층의 위 아래를 나타내는 것이라고 할 수 있다.

 

"HTTP는 TCP와 함께 동작 한다" 라는 말은 다음과 같다.

"사용자의 데이터를 HTTP를 통해 받고, 실제로 이 데이터의 전송은 TCP로 이루어진다" 를 의미 하게 된다.

 

참고 2 :

 

주요 응용 계층 프로토콜 :

 

HTTP (Hypertext Transfer Protocol)

SMTP (Simple Mail Transfer Protocol)

FTP (File Transfer Protocol)

DNS (Domain Name System)

 

내용 3 : OSI 7 계층 기본 개념

 

 

HTTPS의 S는 Secure을 나타낸다고 했다.

이때, 이 Secure == 보안의 기능을 SSL / TLS 프로토콜이 담당 하게 된다.

 

그런데 짚고 넘어 가야 하는 개념이 존재 한다.

 

SSL / TLS 프로토콜은 언제 동작 하는 것일까 ?

 

전송 계층의 TCP 연결 수립이 성공적으로 완료 되면,

이때, 전송할 데이터에 대해 암호화 작업을 시작 한다.

즉, TCP 연결 수립 까지 끝난 이후에 SSL / TLS 프로토콜이 동작 하게 된다.

 

(처음에 1계층 부터 1 2 3 4 5 6 7 순차적으로 거치고, 다시, 7 6 5 4 3 2 1 역순으로 동작)

(위의 내용은 역순으로 가는 경우일 때를 예로 들고 있음)

(위의 개념이 잘못 됬을 경우 수정 필요) 

 

HTTPS가 응용 계층이고, 여기에 S가 SSL / TLS 프로토콜 이라고 해서, 동일한 응용 계층이라고 생각 하면 안된다.

 

SSL / TLS 프로토콜은 OSI 7 계층과는 전혀 무관한 개념 이다.

 

SSL / TLS 프로토콜은 HTTPS에서 보안을 담당 하는 핵심 기술이고, 실질적인 보안 기능은 전송 계층에서 수행 한다.

 

클라이언트와 서버 간의 TCP Handshake가 완료 되어 통신 연결이 정상적으로 수립 되면,

 

그때, SSL / TLS Handshake가 이루어지면서 보안 통신이 설정 되는 것이다.

 

이때, 데이터를 암호화 한 이후, 통신이 진행 된다.

 

이렇게 함으로써, 데이터의 기밀성과 무결성이 보장되고, 중간에서 데이터 변조 및 도청을 방지 하게 된다.

 

4) SSL 디지털 인증서란 ?

 

내용 : SSL 인증서 개요

 

 

SSL 인증서는 클라이언트와 서버 간의 통신을 제 3의 기관에서 보증 해주는 전자화된 문서를 의미 한다.

 

SSL 인증서의 역할은 클라이언트가 접속한 서버가 클라이언트가 정말로 의도 했던 서버가 맞는지를 보장해준다.

 

클라이언트가 서버에 접속한 후, 곧바로 서버는 클라이언트에게 인증서 정보를 전달 한다.

 

클라이언트는 서버가 보내준 인증서 정보가 정말로 신뢰할 수 있는 인증서인지를 검증 한 후,

그 이후의 통신을 위한 다음 절차를 수행 하게 된다.

 

절차에 대한 그림은 아래의 링크에 정리 되어 있다.

 

https://hwanii96.tistory.com/536

HTTP vs HTTPS [2] & SSL

 

5) SSL 인증서를 이용 하는 이유

 

내용 : SSL 인증서 사용 목적

 

 

사용자는 네트워크를 통해 패킷을 주고 받는다.

하지만, 네트워크는 수많은 공격자로부터 위협을 받는 공간 이다.

 

사용자가 특정 서버와 데이터를 주고 받을 때, 수 많은 라우터와 스위치를 거치게 된다.

이 라우터와 스위치를 거치는 중간에서 해커는 사용자의 패킷을 Sniffing (스니핑) 할 수 있다.

 

패킷 및 스니핑 관련 참고 :

 

https://terms.naver.com/entry.naver?docId=2455058&cid=42346&categoryId=42346

스니핑

 

그렇기 때문에, 네트워크 상의 데이터가 암호화 되면 해커는 사용자의 패킷을 훔쳐보더라도 의미가 없게 된다.

 

이때,

'너 님이 정말 신뢰할 수 있는 대상인가요 ?!' 를 판단 하는 정보를 가진 SSL 인증서를 가지고,

클라이언트와 서버 간의 통신을 하는 방법이 생기게 되었다.

 

 

 

SSL 인증서를 사용함으로써의 장점 :

 

1) 클라이언트와 서버 간의 데이터 통신 내용이 공격자에게 노출 되는 것을 막을 수 있다.

 

2) 클라이언트가 접속 하려는 서버가 신뢰할 수 있는 서버인지를 판단할 수 있다.

 

3) 데이터 통신 내용의 악의적인 변경을 막을 수 있다.

 

 

 

인증서 예시)

 

 

 

 

6) SSL에서 사용 하는 암호화의 종류

 

내용 : 대칭 키 vs 비대칭 키

 

 

https://hwanii96.tistory.com/536

HTTP vs HTTPS [2] & SSL

 

위의 게시글에서 이미 학습했듯이, SSL / TLS 는 데이터를 암호화 하는 프로토콜 이라고 했었다.

이미 암호화를 위해 사용 되는 Key에 대한 개념을 학습 했었지만, 아래에서 한번 더 다뤄보려고 한다.

 

SSL / TLS 는 보안 및 성능의 이유로 두 가지 암호화 기법을 혼용 해서 사용 한다.

 

암호화를 할 때 키 (Key) 를 사용 한다.

 

위에서 언급했던 두 가지 암호화 기법으로, 대칭 키 방식과 공개 키 방식이 존재 한다.

 

 

Key는 크게 대칭 키 방식과 공개 키 방식이 있다고 했었다.

 

대칭 키 방식의 장점이 공개 키 (비대칭 키) 방식의 단점이 되고,

대칭 키 방식의 단점이 공개 키 (비대칭 키) 방식의 장점이 된다.

 

대칭 키는 1 개의 키로 암호화 및 복호화를 모두 하기 때문에, 대칭 키 라고 불리게 된다.

 

이와 반대로, 각각의 키로 암호화 및 복호화를 해야 하는 키 방식이 있는데,

 

이때, 암호화를 하는 키는 공개키 라고 하고, 복호화를 하는 키는 개인키 라고 한다.

 

1 개의 키로 암호화 및 복호화를 모두 하는 대칭 키와는 상반 되기 때문에 이러한 방식을 비대칭 키 라고도 한다.

 

흔히, 비대칭 키 방식을 공개 키 방식이라고 부르기 때문에, 상반 되는 대칭 키 방식을 비밀 키 방식 이라고도 한다.

 

위의 내용을 보면 같은 키여도 사용 되는 단어가 여러 가지 이기 때문에, 상당히 혼란스러울 수 있다.

 

 

 

대칭 키 : Symmetric Key 라고 한다.

* Symmetric : 대칭적인 / 균형이 잡힌

 

다른 말로, Secret Key 라고도 한다. (Public Key의 반대 되는 개념이라서)

 

 

 

비대칭 키 : Asymmetric Key 라고 한다.

* Asymmetric : 비대칭의

 

다른 말로, Public Key 라고도 한다. (Asymmetric Key는 Public Key와 Private Key 2개를 갖음)

(Symmetric Key를 다르게 부르는 Secret Key 용어와 Asymmetric Key의 Private Key를 혼동 하면 안된다)

 

내용 2 : 대칭 키 vs 비대칭 키

 

 

대칭 키 : Symmetric Encryption == 비밀 키 == Secret Key

 

 

대칭 키 (Symmetric Encryption) 는 암호화 / 복호화 때 사용 하는 Key가 동일 하다.

 

따라서, 해당 하는 대칭 키 1 개로 데이터를 암호화 및 복호화가 가능 하다.

 

즉, 데이터를 암호화 할 때, hello라는 값을 사용 했으면, 데이터를 복호화 할 때도 hello라는 값을 입력 한다.

 

장점 : 비대칭 키 (Asymmetric Encryption == Public Key == 공개 키) 에 비해 계산 속도가 빠르다.

 

단점 : 1 개의 Key로 암호화 및 복호화를 하는 방식이므로, Key가 유출 되면 데이터 유출이 되어 버린다.

 

따라서, 클라이언트와 서버 간의 동일한 대칭 키를 어떻게 서로에게 전달 할지에 대한 방법을 고려 해야 한다.

 

 

 

비대칭키 : Asymmetric Encryption == 공개 키 == Public Key

 

 

비대칭 키 (Asymmetric Encryption) 는 다른 말로 공개 키 방식 이라고 한다. (Public Key)

 

왜냐 하면, 비대칭 키 방식은 두 개의 Key를 갖는 방식인데,

 

이때, 한 개의 Key를 공개 키 (Public Key) 라고 하고, 다른 한 개의 Key를 개인 키 (Private Key) 라고 한다.

(Private Key는 한국어로 개인 키라고 하며, 그외에 비공개 키 또는 비밀 키 라고도 불린다)

(한국어로 사용 되는 단어가 굉장히 다양하므로, 혼동될 수 있다. 헷갈리면 영어의 뜻을 파악 하고 학습 하자)

 

한 개의 Key로 암호화 및 복호화를 하는 대칭 키와 다르게, 비대칭 키 (공개 키) 는

A라는 Key로 암호화를 하면, 복호화는 반드시 B라는 Key로 해야 한다.

 

복호화를 하기 위한 B라는 Key는 즉, 개인 키를 의미 한다.

 

개인 키는 반드시 본인이 소유 하고 있다.

 

타인에게 넘겨주는 키는 무조건 공개 키 (Public Key) 이다.

 

타인에게 나의 공개 키를 전달 해서, 타인의 데이터 등을 나의 공개 키로 암호화 하고, 다시 나에게 보내주면,

 

나는 나의 개인 키로 타인이 나의 공개 키로 암호화 해서 보내준 데이터를 복호화 한다.

 

설령 타인과의 데이터 통신 중에 나의 공개 키가 유출되더라도, 어차피 나의 개인 키가 없기 때문에,

 

데이터 복호화가 불가능 하다. 즉, 공개 키가 유출 되는 것은 전혀 보안에 상관이 없는 방식 이다. 

 

내용 3 : 대칭 키 vs 비대칭 키

 

 

비 대칭 키 == 공개 키 방식으로 데이터를 암호화 하고 복호화 하는 작업은 일반적으로 다음과 같다.

 

데이터 또는 대칭 키를 암호화 할 때 사용 하는 키 >> 공개 키

 

데이터 또는 대칭 키를 복호화 할 때 사용 하는 키 >> 개인 키

 

즉,

암호화 == 공개 키

복호화 == 비밀 키

이다.

 

그런데, 예외적인 경우가 있다.

 

비밀 키로 특정 데이터 + 공개 키를 서명 한다.

(원래 비밀 키는 복호화를 할 때 사용 하는 키라고 했다)

 

그러면 비밀 키로 암호화된 특정 데이터 + 공개 키를 얻은 특정 사용자는 데이터를 공개 키로 서명을 확인 할 수 있다.

(원래 공개 키는 암호화를 할 때 사용 하는 키라고 했다)

 

이는 위에서 계속 학습 했던 일반적인 상황이 아니다.

 

데이터를 암호화 해서 보호 하기 위함의 목적을 갖는 상황이 아니고,

 

데이터를 제공한 사람의 신원을 보장 해주는 목적을 가지는 상황일 때 위의 방법이 사용 된다.

 

이것을 전자 서명 == 디지털 서명 (Digital Signature) 이라고 한다.

 

디지털 서명은 CA (Certificate Authority) 와 밀접한 관련이 있는 개념이다.

 

https://hwanii96.tistory.com/536

HTTP vs HTTPS [2] & SSL

 

위의 게시글 하단부에 그림으로 표현 되어 있다.

 

7) SSL 인증서를 만들어 주는 인증 기관 (CA == Certificate Authority)

 

내용 : SSL 인증서 개념

 

 

 

인증서의 역할 : 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지를 보장.

 

이러한 인증서를 발급 해주는 민간 기업들을 CA (Certificate Authority) 또는 Root Certificate 라고 한다.

* Certificate : 증명서 / 자격증 / 자격

* Authority : 권한 / 인가

* Certificate Authority : CA : 자격 증명 권한 부여 == 인증 기관

 

SSL/TLS 프로토콜을 통해 암호화된 통신을 제공 하기 위해서는 CA를 통해서 인증서를 구입 해야 한다.

 

CA는 서비스의 신뢰성을 다양한 방법으로 평가 해서 인증서를 생성 하고 제공 한다.

 

인증 기관에 제출 해야 하는 정보는 아래와 같다.

1) 공개키 소유자의 이름, 이메일 주소, 실체를 입증할 수 있는 서류, .. 등등

2) 도메인 이름, 영문 사업자 등록증, 공인된 3자를 통해 수집할 수 있는 인증 전화번호, .. 등등

 

CA는 아무 민간 기업이나 할 수 있는 것이 아니고, 신뢰성이 엄격 하게 검증된 기업들만 참여할 수 있다.

 

대표적인 기업은 아래와 같다.

 

 

 

 

사설 인증서 vs 공인 인증서

 

개발 또는 테스트를 목적을 위해서 SSL/TLS 암호화 프로토콜을 반드시 사용 해야 하는 경우가 있을 수 있다.

 

SSL/TLS 암호화 프로토콜을 사용 하려면, 결국 본인이 직접 CA의 역할을 해서 사설 인증서를 만들 어야 한다.

 

이것은 당연히 공인 인증서가 아니기 때문에, 사설 인증서를 사용한 경우는 다음과 같이 경고를 출력 한다.

 

주의 요함이 뜨게 된다

 

 

반면에 공인된 CA에서 제공 하는 공인 인증서를 전달 받은 브라우저는 아래와 같이 보여 지게 된다.

 

주의 요함이 뜨지 않음.

 

 

 

[ Reference ]

 

인증 기관 - 위키백과, 우리 모두의 백과사전 (wikipedia.org)

Certificate authority - Wikipedia

 

---

 

2. SSL / TLS 인증서 내용

 

1) SSL 인증서의 내용

 

내용 : SSL 인증서 내용

 

 

SSL 인증서에는 다음과 같은 정보가 포함 되어 있다.

 

1) 서비스의 정보 (인증서를 발급한 CA, 서비스의 도메인, .. 등등)

 

2) 서버 측의 공개 키 (공개 키의 정보, 공개 키의 암호화 방법)

 

1) 의 서비스의 정보는 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지를 확인 하는 용도 이다.

 

2)는 서버와 CA가 통신할 때 사용할 서버의 공개 키와 그 공개 키의 암호화 방법들의 정보를 담고 있다.

(이 부분 다시 정리 하기)

 

위에서 언급했던,

서비스의 도메인과 서버 측의 공개 키 등은 CA로부터 인증서를 구입할 때 인증 기관에 제출 해야 한다.

 

 

1) 발급 대상 :

인증서를 발급 받는 주체. 즉, 인증 받고 싶은 서버 이다.

 

2) 발급 기관 :

인증서를 발급 해주는 주체. 즉, 공인 인증서를 발급 해준다고 예시를 들면, CA를 의미 한다.

 

3) 유효성 기간 :

인증서의 발급 날짜 및 유효 날짜를 의미 한다.

 

4) SHA-256 지문 :

여기서는 SHA-256 이지만, 어떤 해시 함수를 사용 했냐에 따라 달라 진다.

 

서버는 사이트 정보 (도메인 등등) 와 공개 키를 CA에게 제출 한다고 했다.

 

그러면, CA는 서버가 정말 괜찮은 서버인지를 검증 한다.

 

그리고 나서 괜찮은 서버 라는게 검증 완료 되면, 서버에게 인증서의 내용을 종합 해서 발급 해준다.

 

근데, 이때 이 인증서 내용을 종합할 때 해시 함수를 사용해서 Hash화 한다.

 

이렇게 Hash화된 인증서 내용을 CA의 개인 키로 암호화한 값을 지문 이라고 한다.

>> "인증서의 발급자 서명"

 

암튼 이렇게 Hash화 되고, CA의 개인 키로 암호화 해서 지문으로 된 인증서 정보를 인증서에 담아서,

 

CA는 서버에게 인증서를 보내주게 되는데,

 

나중에, 클라이언트가 서버 에게 통신 요청을 할 때,

 

클라이언트는 CA에게 받은 CA의 공개 키를 들고 있고,

 

서버가 클라이언트에게 인증서를 넘겨 줄 때,

 

클라이언트는 서버가 넘겨준 인증서 내부의 지문 (Hash화 된 인증서 내용) 과 공개 키를,

 

CA에게 받은 공개 키를 사용 해서, 지문 (Hash화 된 인증 서 내용) 과 공개 키를 비교 해서 일치 하면,

 

인증서가 위조 되지 않았음을 인증 하여 서버 인증서의 무결성을 검증 하게 된다.

 

예시)

 

 

내용 2 : SSL 인증서 내용

 

 

 

위의 정보들은 CA (Certificate Authority) 에 의해 암호화 되고 있다.

 

이 때, 사용 되는 암호화 기법은 공개 키 방식 == 비 대칭키 방식 (Asymmetric) 이다.

 

이때 비 대칭키 방식으로 암호화를 하는 기법은 예외적인 경우 라고 학습 했다.

(SSL / TLS 인증서 개념 - SSL에서 사용 하는 암호화의 종류 - 내용 3번에 서술 되어 있음)

 

CA는 자신의 개인 키를 사용 해서 서버가 CA에게 제출한 인증서를 암호화 한다.

 

CA의 개인 키는 절대로 유출 되서는 안된다.

 

실제로 CA의 개인 키가 유출 되서 파산한 회사가 있었다.

 

SSL 인증기관, 해킹 공격 받아...결국 파산 (boannews.com)

SSL 인증기관, 해킹 공격 받아...결국 파산

 

2) SSL 인증서의 구조

 

내용 : SSL 인증서 구조

 

 

 

인증서는 계층 구조로 이루어져 있다.

2계층 또는 3계층 형태로 이루 어져 있다.

이러한 구조로 인증 하는 방식을 인증서 체인 (Chain of Trust) 이라고 한다.

 

 

위의 이미지를 보면, 인증서 계층 구조를 확인할 수 있다.

 

Root 인증서 == 1 계층 : 

세상 사람들이 모두 신뢰하기로 약속한 기관 이다.

>> DigiCert Global Root CA

 

ICA (Intermediate CA) 인증서 == 2 계층 :

인증서 내용을 생성 하고, Root 인증서로부터 키를 받아 암호화. (신뢰성 입증)

 

개인 인증서 (End-Entity CA) == 3 계층 :

개인이 인증서를 발급 받으려면 Root 인증서가 아닌 ICA 인증서에게 사인을 요청 하게 된다.

* 사인 : 인증서 내용이 담겨져 있는 정보를 CA의 개인 키를 사용 해서, 해시함수로 암호화 한 것.

 

 

 

Root 인증서 (1 계층) 에서 개인 인증서 (3 계층) 으로 바로 인증서 보증을 하지 않는 이유 :

 

1 계층에서 3 계층으로 다이렉트 보증을 하지 않고, ICA 라는 중간 계층이 존재 한다.

 

Root CA가 개인 인증서 까지 바로 서명 하면 좀 더 직관적이고 쉬운 구조가 될 수 있겠지만,

 

ICA (중간 인증서 CA) 에게 서명을 받아 3계층의 형태를 만드는 이유는 다음과 같다.

 

1) 인증을 수행 하는 기관의 인증서가 손상되거나 또는 개인 키가 유출 되는 경우에 철회가 가능 하도록 함.

 

2) Root 인증서가 직접 개인 인증서에 서명 하는 것보다 한 단계의 인증 Layer가 있기 때문에,

더 강력한 보안 체계를 구축할 수 있게 된다.

 

결론은 강력한 보안 체계를 위해서 인증서를 3 개의 계층 구조로 구축 한다.

 

 

 

[ 추가 정리 ]

 

Root 인증서 :

 

보통 인증서 구조는 3 계층 구조로 되어 있다.

 

이때, 가장 최상위에 위치 하는 인증서를 일반적으로 Root 인증서 라고 한다.

 

Root 인증서는 세상 모든 사람들이 모두 신뢰 하기로 약속한 CA에서 발행한 인증서 이다.

 

웹 브라우저에는 Root 인증서와 루트 인증 기관의 공개 키 모두를 기본 내장 하고 있다.

 

Root 인증서는 스스로를 사인해 줄 상위 CA가 없기 때문에, 스스로를 셀프로 보증 하게 된다.

 

 

 

ICA (Intermediate CA) :

 

ICA는 단어 뜻 그대로 중간 인증서 이다.

 

ICA는 루트 인증서 대신에 사용 되는 인증서 이다.

 

루트 인증서는 수 많은 보안 계층 뒤에 보관 해야 하기 때문에, 중간 인증서는 Proxy로 사용 된다.

 

실제 웹 브라우저에서는 최상위 인증서 기관인 Root CA와 중간 인증서 기관인 ICA 까지는,

 

사실상 무조건적으로 신뢰할 수 있도록 설정 되어 있기 때문에,

 

우리가 특별히 Root 인증서와 ICA 인증서에 대해 의심할 필요는 없다고 보면 된다.

 

 

 

Chain of Trust (인증서 체인) :

 

상위 계층의 인증서가 신뢰할 수 있는 기관이라면,

 

해당 상위 계층의 인증서의 개인 키로 하위 계층의 인증서 또한 신뢰 가능 하다고 간주 한다.

>> Chain of Trust (인증서 체인)

 

다시 말해서, 이미 신뢰할 수 있는 기관에 의해 인증서가 발급 됬으면,

 

해당 기관의 개인 키로 하위 계층의 인증서를 발급 하는 것에 대한 신뢰를 전파 하는 개념 이다.

 

(인증서를 생성할 때 개인키로 서명을 해서 생성 하는 개념 이다)

 

3) SSL 개인 인증서를 신뢰할 수 없다면 ?

 

내용 :

 

 

우리가 신뢰 하는 기관은 이미 정해져 있다고 했다.

 

Root CA와 같은 기관들이 이에 해당 한다.

 

신뢰할 수 없는 인증서라는 것은 우리가 신뢰할 수 없는 제 3의 기관이 발급한 인증서 라는 뜻이다.

 

신뢰할 수 없는 인증서를 사용 하는 웹 페이지에 접속할 경우, 

 

암호화된 패킷이 제 3자에 의해 복호화 될 수 있기 때문에,

 

데이터가 유출되거나 인증서가 변조 되는 등의 보안 상의 취약점이 발생 하게 된다.

 

이런 경우 웹 브라우저는 신뢰할 수 없는 인증서 라는 경고를 출력 하거나 접근 자체를 막는다.

 

 

 

---

 

3. SSL / TLS 인증서 작동 원리

 

1) SSL 인증서 보안 연결 수립 Process

 

내용 : SSL 동작 방법

 

 

SSL은 암호화된 데이터 (메세지) 를 전송 하기 위해서 대칭키 + 공개키 방식을 혼합 해서 사용 한다.

 

즉, 결국에 클라이언트와 서버가 주고 받는 실제 데이터는 대칭키 방식으로 암호화 하고 복호화 하지만,

처음에 교환하는 대칭키를 안전하게 교환 하기 위해서 공개키 방식으로 교환 하는 것을 의미 한다.

 

정리하자면, 

실제 데이터 == 대칭키 방식으로 교환

첫 대칭키 교환 == 공개키 방식으로 교환

 

내용 2 : SSL 동작 방법

 

 

SSL (Secure Socket Layer) 동작 방법

 

컴퓨터와 컴퓨터가 네트워크를 이용 해서 통신 할 때, 내부적으로 3단계로 진행 된다.

 

아래의 과정은 은밀하게 일어나는 과정이므로 사용자에게는 노출 되지 않는다.

 

악수 (Handshake) - 전송 (Session) - 종료 (Session 종료)

 

 

1. 클라이언트 Hello :

 

클라이언트가 HTTPS 프로토콜 방식으로 서버에게 접속 요청을 보낸다. ( 예) Hello )

 

TCP 연결 수립이 성공적으로 수행 되면, 곧바로 SSL/TLS 프로토콜을 수행 하게 된다.

 

SSL/TLS 프로토콜은 TCP 프로토콜 위에서 동작 한다.

따라서, SSL 핸드셰이크 과정은 TCP 연결 이후에 이루어 지게 된다.

 

첫 과정으로 SSL/TLS 핸드셰이크가 일어난다.

 

이때, 클라이언트는 무작위로 랜덤 데이터 (32 Byte)를 생성 한다.

 

이 데이터는 핸드셰이크의 안전성을 강화 하기 위해서 사용 된다고 보면 된다.

 

이 무작위의 랜덤 데이터에는 타임스탬프, 임의의 데이터, Session ID 등이 포함 된다.

 

그리고, 사용 가능한 암호화 방식 후보들 (암호화 알고리즘 목록들) 이 존재 한다.

 

이것을 SSL / TLS 인증서 개념 - SSL 프로토콜의 구조 - 내용 1 에서 Cipher Suite라고 했었다.

 

즉, 통신 보안을 정의 하기 위해 SSL 프로토콜에서 사용되는 개념 이다.

 

Cipher Suite에는,

키 교환 알고리즘 , 인증 알고리즘 , 대칭 암호 알고리즘 , 블록 암호 알고리즘 , 해시 알고리즘 등이 포함 된다.

 

요약 하자면, 처음에 클라이언트가 서버에게 Hello라는 요청을 보낼 때, 랜덤 데이터 + Cipher Suite를 보낸다.

 

2. 서버 Hello :

 

서버는 클라이언트에게 요청을 받고, 서버 자신의 랜덤 데이터를 생성 한다.

 

그리고 클라이언트에게 정의된 Cipher Suite + CA로 부터 인증된 서버의 디지털 인증서가 있다.

 

서버는 클라이언트에게 서버의 랜덤 데이터 + Cipher Suite + 디지털 인증서를 전달 한다.

 

3. 인증서 확인 & pre master secret :

 

클라이언트는 우선적으로 인증 기관으로 부터 받은 공개키를 사용 해서, 서버가 보내준 인증서를 확인 한다.

 

그리고, 자신의 랜덤 데이터와 서버에서 보내준 랜덤 데이터를 조합 해서 pre master secret 키를 생성 한다.

 

여기서 말하는 pre master secret 키는 임시 대칭키를 의미 한다.

 

4. pre master secret 암호화 :

 

클라이언트가 생성한 임시 대칭키에 서버가 전송 해준 인증서 내부의 서버 공개키를 사용 해서 암호화를 한다.

 

그리고, 암호화된 임시 대칭키 (pre master secret) 를 서버로 전송 한다.

 

5. pre master secret 복호화 :

 

서버는 자신의 개인키로 클라이언트가 보내준 암호화된 임시 대칭키를 복호화 한다.

 

그러면 클라이언트와 서버는 서로 동일한 임시 대칭키를 들고 있는 상태가 된다.

 

6. master secret 및 session key 생성 :

 

pre master secret == 임시 대칭키는 일련의 과정을 거쳐 최종적으로 master secret 키가 된다.

(위에서 말하는 일련의 과정의 디테일적인 부분은 추후에 다시 정리할 예정)

 

여기서 말하는 master secret 키는 다른 말로, session key라고도 부르고, 최종적인 대칭키를 의미 한다.

 

7. session key를 활용한 대칭키 암호화 방식 통신 :

 

클라이언트와 서버는 서로 같은 대칭키를 갖게 됬으므로, 이 대칭키를 사용 해서 데이터 송수신을 하게 된다.

 

8. 세션 종료 (session key 폐기) :

 

세션이 종료된다는 말은, 클라이언트와 서버간의 통신이 이루어지고 있음을 의미 하는 세션 기간 만료 

또는, 웹 브라우저를 종료한 경우 등을 의미 한다.

 

이렇게 클라이언트와 서버간의 통신이 종료 되면, 양쪽에 대칭키는 폐기 된다.

 

[ 참고 ]

 

클라이언트는 생성한 session key (대칭키) 를 RAM에 저장 한다고 한다.

 

session key를 RAM에 저장함으로써, 클라이언트는 해당 세션 동안 효과적으로 대칭키를 관리 하고,

보안적인 측면에서도 RAM 내의 데이터에 대한 접근을 제어해서 안전한 통신을 유지할 수 있게 된다.

 

---

 

4. SSL / TLS 인증서 종류

 

1) 발급 기관에 따른 SSL 인증서 종류

 

내용 : 공인 인증서 (CA == Certificate Authority) vs 사설 인증서

 

 

 

공인 인증서 :

 

1) CA에서 발급 받은 공인된 인증서

 

2) 인증서를 발급 받기 위해서 별도의 심사 과정을 거쳐야 함

 

3) 주기적으로 갱신이 필요 하고, 별도로 비용을 지불 해야 함

 

4) 일반적으로 인터넷을 통해 접근 하는 사이트들은 모두 공인 인증서가 적용 되어 있음

 

5) 사용자가 PC에 별도로 인증서를 설치 하지 않더라도, 문제 없이 https 방식으로 통신 하는 웹사이트 사용 가능

 

사설 인증서 :

 

1) CA를 통해 발급 받지 않은 인증서

 

2) 별도의 심사 과정이 필요 없고 비용이 들지 않음

 

3) 신원이 확실해서 인증 기관의 인증이 없어도 되는 경우 사용

 

4) 내부망에서 이루어지는 통신이라 할지라도 보안 인증 관련으로 https 방식으로 통신을 해야 하는 경우가 있음

이런 경우에는 결국 인증서가 필요 하기 때문에 사설 인증서를 적용 하는 경우가 있음

 

5) 사용자의 PC에 별도로 인증서를 설치 해야 함

 

2) 심사 수준에 따른 SSL 인증서 종류

 

내용 : DV (Domain Validation), OV (Organization Validation), EV (Extended Validation)

 

 

* DV : Domain Validation

* OV : Organization Validation

* EV : Extended Validation

 

DV >> OV >> EV 로 갈수록,

인증서 발급의 소요 시간이 커지며, 가격도 올라 가고, 요구 되는 최소 보안 수준이 높아 진다.

 

 

 

DV : Domain Validation

 

- 도메인을 소유 했는지를 검증 하는 절차만 존재.

 

- 가장 간단 하고, 누구나 5분 만에 발급이 가능.

 

인증서의 주체가 되는 값 : 도메인 

따라서 도메인 검증 작업이 이루어진다.

 

 

OV : Organization Validation

 

- 도메인 소유 검증 절차 + 조직 검증 절차.

 

- 최대 3일 정도 소요.

 

- 일반적으로 대기업에서 사용.

 

인증서의 주체가 되는 값 : 도메인 + 조직

따라서 도메인과 조직 검증 작업이 이루어진다.

 

 

EV : Extended Validation

 

- 도메인 소유 검증 절차 + 구체적인 조직 검증 절차.

 

- 최대 3주 정도 소요.

 

- 보통 금융권 및 공공 기관 등 보안이 강력 해야 하는 대기업 에서 사용.

 

- DV (Domain Validation), OV (Organization Validation) 과 달리 브라우저에 따라 Green Bar 등으로 차별화.

 

- 사용자가 한 눈에 신뢰 사이트 라는 것을 확인할 수 있도록, 브라우저의 주소 창이 녹색으로 표시 된다.

 

- EV 인증서를 발급 받기 위해서는 까다로운 인증 절차 및 신원 보증 등이 확인 되어야 구축이 가능 하다.

 

인증서의 주체가 되는 값 : 도메인 + 조직

따라서 도메인과 조직 검증 작업이 이루어진다.

 

 

 

 

 

3) 도메인에 따른 SSL 인증서 종류

 

내용 :  Single SSL Certificate / Multi-Domain SSL Certificate / Multi-Domain Wildcard SSL Certificate

 

 

추가 정리

 

4) 인증서 포맷에 따른 SSL 인증서 종류

 

내용 : 인코딩 체계, 인증서 확장자 별 특징

 

 

추가 정리

 

---

 

5. ISVA 내부 SSL 인증서 관리

 

1) ISVA (IBM Security Verify Access) 기본 SSL Certificates Database 종류

 

https://hwanii96.tistory.com/539

ISVA 내부 SSL 인증서 관리

 

2) 사설 인증서 생성 방법

 

https://hwanii96.tistory.com/539

ISVA 내부 SSL 인증서 관리

 

3) Tomcat 사설 인증서 생성 및 ISVA 내부 SSL 인증서 등록 방법

 

https://hwanii96.tistory.com/539

ISVA 내부 SSL 인증서 관리