728x90

SSL :

암호화를 수행하지 않으면 스니퍼(Sniffer)라는 네트워크 패킷 모니터링 도구를 사용해서 송수신되는 모든 데이터를 볼 수 있게 된다. 보안 서버의 구축은 SSL 및 SSO 등으로 구축할 수 있으며 공개용 인터넷에서 사용하는 방식은 SSL이다.

 

SSL(Secure Sockey Layer)

Netscape사에서 개발한 인터넷과 같은 개방 환경에서 Client와 Server사이의 안전한 통신을 위해 개발했다.

암호문 전송을 위해 RSA 공개 키알고리즘 사용, X.509 인증서 지원, 443번 포트 사용, Transport Layer(4계층) ~ Application Layer(7계층)에서 동작(http, ftp, telnet, mail)한다. 비밀성, 무결성, 인증의 3가지 보안 서비스를 제공한다. 

웹 상에서의 거래 활동을 보호한다.

 

SSL은 송신되는 데이터를 암호화하고 송신 과정에서 변경되었는 확인할 수 있게 무결성을 지원한다. 또한 사용자 패스워드를 사용해서 인증을 수행할 수도 있다.

 

(1) SSl 보안 서비스 (보안 3대 요소 :  기무가, 기밀성 무결성 가용성) 

인증 : 거래하고자 하는 사이트가 신뢰되고 검증된 사이트인지 개인정보를 송신하기 전에 먼저 상대 사이트를 인증하는 기능

무결성 : 송신자측의 PC에서("브라우저") 상대편 웹서버까지의 송신 중 공격자나 제3자에 의해 무단으로 데이터가 위변조되는 것을 방지하는 기능으로 중요한 역할을 함.

기밀성 : DES, 3DES, IDEA 등 여러 가지 암호화 방식을 사용하여 데이터의 송수신 중에 인가되지 않은 사용자의 데이터에 대한 불법적인 접근을 통제하고 만일의  경우 데이터가 공격에 의하여 유출되었다 하여도 쉽게 읽혀질 수 없는 형태로 변환시키는 기능

 

(2) SSL Handshaking : SSL로 요청 전에 웹브라우저는 웹 서버 포트 443 포트를 호출하여 3 Way Handshaking을 수행

SSL에서 Random이라는 것은 재생공격(replay attack)을 방지하기 위한 임의적 숫자이다. 웹서버가 Client Hello 메시즈를 수신 받으면 사용할 암호화 알고리즘을 결정해서 웹브라우저에게 Server Hello 메시지를 전송한다.

 

웹 브라우저는 최종적으로 "Change Cipher Spec"이라는 것을 웹 서버에 전송해서 웹브라우저와 웹서버간의 협상을 마친다 

 

웹브라우저와 웹서버간에 협상이 완료되면 이제 실질적으로 데이터 암호화를 수행한다. 

 

(3) SSL 구성 요소 

Change Cipher Spec Protocol :

Alert Protocol :

Record Protocol :

 

(4) SSL Handshaking Protocol 세부 과정 

Client Hello : Hand Shake Protocol 의 첫단계로 클라의 브라우저에서 지원하는 암호 알고리즘, 키교환 알고리즘, MAC 암호화, HASH 알고리즘을 서버에게 전송함. (클라가 보내는 Hello)

Server Hello : Client Hello 메시지 내용 중 서버가 지원할 수 있는 알고리즘을 클라에게 전송함

Server Hello Done : 클라이언트에게 서버의 요청이 완료되었음을 공지함. (SYN+ACK ??)

Premaster Key 전송 : 전달받은 서버의 인증서를 통해 신뢰할 수 있는 서버인지 확인 후 암호통신에 사용할 'Session Key'를 생성하고 이것을 서버의 공개키로 암호화해 'Premaster Key'를 만들어 서버로 전송함. (!!!)

Change Cipher Spec : 앞의 단계에서 협의된 암호 알고리즘을 이후부터 사용한다는 것을 서버에게 알림

Finished : 서버에게 협의의 종료를 전달함

Change Cipher Spec : 서버 또한 클라의 응답에 동의하고 협의된 알고리즘들의 적용을 공지함

Finished : 클라에게 협의에 대한 종료를 선언함.

 

==

인터넷을 통해 클라이언트와 서버가 통신할 때 통신내용을 안전하게 보호하는 방법으로 SSL(Secure Sockets Layer)을 사용할 수 있습니다. SSL은 서버인증(Server Authentication), 클라이언트인증(Client Authentication) 그리고 데이터암호화(Data Encryption)기능을 제공합니다. 

 

인증은 통신의 상대방이 맞는지 확인하는 절차를 의미합니다. 암호화는 데이터가 누출되더라도 외부에서 이 내용을 해독할 수 없게 하는 것을 의미합니다.

 

SSL을 사용하는 URL은 https라는 스킴(scheme)을 사용하여 구분합니다. 최근 버전의 SSL은 TLS(Transport Layer Security)라고 이름이 바뀌었습니다. 현재 IETF(Internet Engineering Task Force)가 TLS표준을 유지관리하고 있습니다.

 

공개키, 비밀키, 인증서(public key,  private key, certificates)

인증을 수행할 때 SSL은 공개키암호화(public-key cryptography)라는 기술을 사용합니다. 공개키암호화는 공개키와 비밀키 이 둘의 조합에 근거한 알고리즘입니다. 공개키로 암호화된 데이터는 그 공개키와 짝이 되는 비밀키에 의해서만 해독이 가능합니다. 반대로 비밀키로 암호화된 데이터 역시 짝이 되는 공개키로 해독할 수도 있습니다.

 

이 키 쌍을 가지고 있는 소유자는 이 중 공개키를 아무에게나 공개할 수 있습니다. 하지만 비밀키는 잘 보관해야 하니다. 인증서는 소유자의 공개키가 맞는지를 검증하는 도구입니다. X.509표준을 준수하는 인증서는 다음과 같은 데이터와 서명 영역을 가지고 있습니다.

 

공개키를 소유하고 있는 자의 구별 가능한 이름

공개키를 발급한 자의 구별 가능한 이름

이 인증서가 언제까지 유효한지를 나타내는 유효기간

공개키 그 자체

 

VeriSign과 같은 인증기관(CA, Certificate Authority)을 통해 인증서를 발급 받을 수도 있고 스스로 자기 서명 인증서(Self-signed Certificate)를 만들 수도 있습니다. 스스로 인증서를 만들었을 경우, 소유자와 발급자가 같습니다. 인증서를 발급하는 인증기관은 서로간에 어떤 계층관계가 있습니다. 루트 CA는 자기 서명 인증서를 가지고 있습니다. 하지만 그 하부 CA들은 자기 직속상관이 발급한 인증서를 가지고 있습니다. 그래서 특정CA는 이런 인증서들의 묶음을 가지게 되는데 이를 인증서체인(Cerficate chain)이라고 합니다. 

 

인증서체인은 자기 직속 상위 CA가 발급한 인증서를 가지고 있고, 그 상위 CA는 또 그 위의 상위 CA가 발급한 인증서를 가지고 있는 식입니다.

 

출처: https://brownbears.tistory.com/232

 

[Linux] OpenSSL 인증서

OpenSSL이란?인터넷을 통해 클라이언트와 서버가 통신할 때 통신 내용을 안전하게 보호하는 방법으로 SSL(Secure Sockets Layer)을 사용할 수 있습니다. SSL은 서버 인증(Server Authentication), 클라이언트 인

brownbears.tistory.com

 

 

==

예2)
"SSL 신청할려고 하는데 CN 항목에, 내 도메인 입력하면 되나요?" 라고 할때 "네. 도메인 입력하시면 됩니다" 와 "FQDN 입력하세요" 중 어떤게 더 착오를 줄일수 있을까요?

소유한 도메인중에, SSL 인증서를 적용하려면 적용 대상 FQDN 을 정확히 이해를 하고 발급 신청을 해야만 착오를 줄일수 있습니다. 그래야만, mail.domain.com 에 SSL 을 적용하는 것인데 domain.com 으로 된 인증서를 발급 받는 일이 발생하지 않습니다.




위와 아래는 다른 FQDN 입니다.



또한 종종 잘못 이해되고 있는 부분은, SSL 에서는 URL 과 도메인은 서로 의미가 다릅니다.

그래서 이런 모호함을 없애기 위해서 FQDN 이란 단어가 필요하고, 위 예제에 있는 도메인을 각각 완전히 고유하게 지칭할때 FQDN 이라고 합니다.  FQDN 기준으로는, www 가 붙은것과 안붙은것은 엄연히 다르며 절대 같은 도메인이 아닙니다. 글자 한자라도 다르면 별개이며, 엄격하게 구분하는 것입니다.

SSL 신청시 도메인은, 웹브라우저 주소창에서 보이는 실제 사용하는 URL 주소의 FQDN 기준이어야 합니다

 

 

 

 

 

 

 

 

https://www.sslcert.co.kr/guides/kb/51

+ Recent posts