본문 바로가기

기타

SSL/TLS

SSL/TLS

SSL(Secure Sockets Layer)은 웹사이트와 브라우저 사이(또는 두 서버 사이)에 전송되는 데이터를 암호화하여 인터넷 연결을 보호하기 위한 프로토콜,  

TCP/IP 네트워크를 사용하는 통신에 적용되며, 통신 과정에서 전송계층 종단간 보안과 데이터 무결성을 확보해준다.

 

TLS(Transport Layer Security)는 SSL의 업데이트 버전으로,

SSL의 최종버전 3.0과 TLS의 최초버전은 차이가 크지 않다.

 

Nerscape Communication이라는 회사에서 WWW(World Wide Web)의 통신을 안전하게 유지하는 것을 목적으로 SSL이 발명 되었고, 이것이 점차 폭 넓게 사용되며 표준화 기구인 IETF(Internet Engineering Task Force)의 관리로 변경되어 TLS라는 이름으로 변경되었다.

현재는 SSL의 보안 문제로 인해 모든 버전이 사용되고 있지 않지만 TLS라는 이름보다 SSL이라는 이름을 주로 사용된다.

 

SSL VS TLS

구분 SSL TLS
버전 최종 3.0
현재는 IETF에 의하여 모든 버전
사용 중지
최신 버전은 1.3
보안 취약점 존재 SSL의 보안강화
핸드셰이크 명시적 연결 암시적 연결
알림 메시지 경고와 치명적 두가지 존재,
암호화 되지 않음
경고, 치명적, 닫기 세가지가 존재
추가보안을 위해 암호화
메시지 인증 MAC방식 (MD5알고리즘) HMAC방식
암호 그룹 구식 알고리즘 사용 보안 문제로 복잡하고 다양한
알고리즘 사용

*MAC - Message Authentication Code, MAC이란 메시지 인증코드로, 메시지를 받은 사람이 위변조가 되었는지 판단하는 방법으로 무결성과 신뢰성을 보장하지만, 부인 방지는 할 수 없다.(제 3자가 대칭키를 해킹하여 MAC값을 생성 후 보낼 수 있기 때문)

HMAC - Hash-based Message Authentication Code, HMAC은 해시 함수의 특징을 사용한 메시지 인증코드로, 메시지의 무결성을 보장하며, 공유된 키를 함께 해시하여 부인방지 또한 보장한다.

 

 

 

 

SSL/TLS의 암호화 종류

대칭키

하나의 키를 통하여 암복호화가 가능한 기법으로, 1234라는 암호를 통하여 암호화한 경우 복호화를 위해서도 1234라는 값을 사용해야만 복호화가 가능하다.

하나의 키를 통하여 암복호화가 이루어지기 때문에 계산속도가 빠르지만 키가 유출된 경우 해당 키를 통하여 접근을 허용하게 되는 답점을 갖고 있다.

 

공개키

공개키 방식은 두개의 키를 갖는데, 암호화만 가능한 공개키와 암복호화가 가능한 비공개키 두개의 키를 보유하며

비공개키는 자신만 갖고 있고, 공개키를 제공하여 정보를 암호화한 후 자신에게 제공 받아, 데이터를 안전하게 암호화한다.

공개키가 유출되더라도 암호화만 가능하기 때문에 정보의 보호가 가능하다.

또한 공개키를 통해서 복호화한다고 하는데, 실상은 전자서명 (Digital Signature)를 만들어 전달시

해당 전자서명을 보낸 사용자의 신원을 검증하기 위한 목적으로 복호화하는 것

 

 

 

 

SSL/TLS의 작동방식

개인정보 보호를 제공하기 위해, 웹에서 전송되는 데이터를 암호화한다.

클라이언트와 서버간에 핸드셰이크를 통해 인증이 이루어지며,

데이터 무결성을 위해 데이터에 디지털 서명을 하여 데이터가 의도적으로 도착하기 이전 조작된 여부를 확인한다.

 

SSL동작시

1. 클라이언트 헬로

    클라이언트에서 서버에 접속을 시도하고, 지원하는 암호화 알고리즘과 목록, 무작위의 데이터를 포함한

    Client Hello메시지를 보냄

2. 서버 헬로

    서버는 클라이언트의 요청을 받아, 클라이언트가 지원하는 알고리즘 중, 하나를 선택하여 알고리즘으로

    생성된 임의의 무작위 정보를 암호화하고 이 정보와 인증서를 Server Hello 메시지로 응답

3. 서버 인증 및 키 교환

    클라이언트는 서버 인증서를 확인하여 인증서의 유효성을 체크하고, 서버의 공개키를 추출

4. 프리 마스터 시크릿 생성

    클라이언트의 무작위 암호화 정보와 서버의 무작위 암호화 정보를 조합하여 서버에게 프리마스터시크릿 값을

    만들어 전달하는데 서버로부터 받은 공개키로 암호화하여 전달한다.

5. 세션 키 생성

    서버의 공개키로 암호화된 시크릿값을 서버 비공개키로 복호화하여 서버와 클라이언트가 동일한 시크릿 값을

    갖도록 하고 시크릿 값을 갖고 대칭키를 생성한다.

6. 대화 시작

    클라이언트와 서버는 대칭키(세션키)를 사용하여 데이터를 주고 받는다.

7. 세션 종료

    통신이 종료되면 내부에 종료를 알리고 대칭키는 폐기된다.

해당 순서로 동작한다.

 

 

 

HandShake (핸드셰이크)

핸드셰이크는 악수를 의미하는데, 통신을 하는 브라우저와 웹 서버가 서로 암호화 통신을 시작 할 수 있도록 신분을 확인하고, 필요한 정보를 클라이언트와 서버가 주고 받는 과정을 말한다.

 

 

Digital Signature (디지털 서명 / 전자서명)

서명자를 확인하고 서명자가 했다는 사실을 나타내는 특정 전자적 형태의 정보

서버에 요청으로 응답되어야 하는 데이터를 디지털 서명과 함께 보낸다고 가정할때,

데이터를 hash함수를 이용하여 식별자(Signature)를 생성하여 암호화된 데이터를 만들고,

데이터와 암호화된 식별자, 키를 하나의 전자정보로 만들어, 수신자에게 보냄

 

수신자측에선 받은 문서의 데이터를 다시 한번 Hash함수로 식별자를 생성하고

저장된 키로 복호화하여 전달받은 식별자가 해당 키와 연관이 있는 데이터가 맞는지 신원을 검증하고

Hash함수로 만들어진 데이터를 비교한다.

 

*중간에 데이터를 인터셉터해서 데이터를 상이하게 변경하고, 다시 해싱처리(포장)해서 보내면 데이터 무결성 위반.

즉, 데이터의 변경을 알지 못하는것 아닌가?

중간자 공격이라는 송신자와 수신자 사이에 위치하여 데이터를 가로채고 변경하는 공격법으로 해당 공격에 대비하기 위함 등등의 이유로 인증서 체인의 방법이 탄생하였다.

 

 

 

SSL/TLS 인증서

SSL/TLS 인증서는 데이터 통신을 보호하기 위해 탄생하였다.

주로 데이터의 암호화 웹사이트의 신뢰성을 보장하기 위해 만들어졌는데,

그렇기 때문에 인증서에는 해당 웹사이트가 신뢰성이 있다는 인증서를 발급한 기관에 이름과 정보가 포함된다.

 

해당 인증서는, SSL/TLS 자체가 아닌 SSL/TLS를 사용하는 서버, 즉 핸드셰이크 과정에 적용될 기능 중 하나이다.

 

 

인증서의 구성요소로,

발급자(Issuer) : 인증서를 발급한 기관(CA)의 이름과 정보, 인증서의 신뢰성을 기관이 보증

주체 (Subject) : 인증서가 발급된 대상(서버,조직,개인)의 정보, 서버의 도메인 이름이 포함된다.

공개키 (Public key) : 암호화 통신에 사용되는 공개키(주체), 해당 키를 통해 데이터를 안전하게 암호화하고 전송

유효기간 (Validity) : 인증서의 시작날짜와 만료날짜를 나타내며, 해당 기간동안 인증서가 유효함

인증서 서명 알고리즘 (Signature Algorithm) : 해당 인증서의 알고리즘 유형, 인증서의 진위를 검증하는데 사용된다.

인증서 지문(Fingerprint) : 인증서의 무결성을 확인하는데 사용되는 고유 해시 값

확장 필드 (Extensions) : 추가 기능을 제공하는 확장 필드, 인증서의 사용범위, 키 사용제약, 대체 이름등등이 포함된다.

시리얼 넘버 (Serial Number) : 각 인증서에 고유하게 할당된 식별 번호

 

 

SSL/TLS 란 무엇이고 어떻게 구현하는가? (with Python) - Devitworld

SSL(보안 소켓 레이어)과 TLS(전송 계층 보안)는 인터넷에서 데이터를 안전하게 전송하기 위한 표준 기술입니다. 이 기술들은 웹 브라우저와 서버 간의 데이터 전송을 암호화하여 개인정보, 금융

kr.devitworld.com

 

 

주로 인증서를 발급하는 발급기관인 CA(Certificate Authority)에 의해 발급되며, 인증에 포함된 공개키로 암호화가 가능하다.

 

 

 

 

SSL/TLS인증서 절차

더보기

클라이언트는 연결이전부터, 인가된 CA 리스트를 갖고 있다.

*CA리스트에는 CA의 공개키도 함께 갖고있다.

 

CA인증을 요구하는 서버에서 CA에 인증서 발급요청을 하게 되는데,

서버의 공개키, 서버의 정보, 도메인등등의 정보를 제출하고,

CA에서는 신뢰여부(검증)를 체크 후 제공받은 서버 공개키를 해시함수(ex.SHA256) 처리하여 지문으로 등록한다.

해당 지문을 다시 한번 CA개인키(비밀키)로 암호화하여 서명으로 등록하고,

인증서에 서버 공개키와, 암호화한 서명, CA정보 등등을 첨부하여 인증서를 발급한다.

 

이후 클라이언트에서 서버에 연결요청을 하게 되면, 

서버에서는 연결 응답과 함께, 인증서를 전달하게 된다.

클라이언트에서는 해당 인증서에 보증을 하는 CA를 CA리스트에서 조회하고

인증서에 서명을 저장되어있는 CA 공개키로 복호화한다.

인증서에서 제공받은 서버의 공개키를 해시함수하여 복호화한 데이터와 해시한 데이터를 비교,

 

참일시 대칭키를 생성하고 서버의 공개키로 대칭키를 암호화하여 서버에 전달한다.

서버에서 제공받은 암호호화된 대칭키를 서버의 개인키(비밀키)로 복호화하여 클라이언트의 대칭키를 확인한다.

해당 대칭키를 이용하여, 서버와 클라이언트가 데이터를 암호화하여 통신한다.

 

TLS(SSL) - 2. 인증서, CA, SSL 인증서를 통해 서버를 인증하는 방법

안녕하세요. 소들입니다 :D 저번 시간에 TLS의 정의, 암호화 방식에 대해 알아봤죠? 이번엔 TLS 인증서에 대해 공부해볼 거예요. •'-'•)و✧ 복습을 하자면 TLS의 암호화 방식은 대칭키 방식 + 비대

babbab2.tistory.com

 

호다닥 공부해보는 x509와 친구들

Overview 종종 Web App을 개발할때나 Docker혹은 Kubernetes에 접속할 때 다음과 같은 에러를 만날때가 있습니다. x509 certificate signed by unknown authority 그리고 인터넷 서핑을 하다보면 위 사진과 같이 “Your c

gruuuuu.github.io

 

'기타' 카테고리의 다른 글

P2P (Peer to Peer) VS Master/Slave  (0) 2024.05.27
인증서 파일 형식  (0) 2024.05.17
[LDAP] Suffix, Schema, ObjectClass, DN  (0) 2024.05.09
DNS와 Hosts File(호스트 파일)  (0) 2024.05.03
DHCP VS Static IP  (0) 2024.05.02