SSL (Security Socket Layer)에 대해서 알아보자
- SSL은 OSI 7 Layer 중 어디에서 적용될까
- http에서 https로 redirect되는 원리는 무엇일까
SSL이란 무엇인가?
Security Sockets Layer의 약자로 암호화 기반 인터넷 보안 프로토콜이다.
인터넷 통신의 개인정보 보호, 인증, 데이터 무결성을 보장하기 위해 Netscape에서 1995년 처음 개발 됐다.
SSL은 현재 사용되고 있는 TLS의 초기 버전이라고 할 수 있다.
SSL 1.0은 일반에 공개되지 않았고, SSL 2.0은 심각한 결함이 있었다고 한다.
이런 결점을 극복하고 출시된 것이 1996년 SSL 3.0이다.
TLS (Transport layer Security)는 1999년 IETF (Internet Engineering Task Force)가 SSL에 대한 업데이트를 제안했고, 이 업데이트가 되면서 Netscape가 더 이상 참여하지 않게 되어 이름이 TLS로 변경됐다.
SSL 3.0과 TLS 두 프로토콜은 크게 차이가 있지는 않고, 소유권 변경으로 인해 이름이 변경됐다고 한다.
SSL/TLS를 사용하는 웹사이트의 URL에는 HTTP대신 HTTPS가 붙는다.
기존 일반 텍스트 형식으로 전송됐을 때 보안성이 취약하여 주요 정보를 마음만 먹으면 누구나 읽을 수 있었다.
신용 카드 정보를 탈취 당할 수도 있다는 문제였다. 이런 문제를 해결하고자 암호화를 하기 시작했다.
그렇다면 이 보안 프로토콜은 어떻게 동작할까?
- 웹에서 전송되는 데이터를 암호화 한다.
- 핸드셰이킹 인증 프로세스를 통해 두 장치의 ID를 확인한다.
- 데이터 무결성을 제공하기 위해 디지털 서명을 하여 조작되지 않음을 확인한다.
SSL은 비대칭 암호화 방식을 사용한다.
퍼블릭 키와 프라이빗 키를 활용한다.
모든 정보를 비대칭 암호화 할 경우 성능에 문제가 발생할 수 있어, TLS는 세션 시작부에서 비대칭 암호화를 사용해 이 문제를 해겨했다.
공유 키를 사용한 암호화 과정은 대칭 암호화라고 한다. 이 경우는 비대칭 암호화보다 훨씬 컴퓨터의 리소스를 적게 소모하며, 이미 세션 키를 비대칭 암호화를 사용해 설정했기 때문에 커뮤니케이션 세션 전체는 더 안전하게 사용할 수 있다.
이런 세션 키의 합의 과정을 일컬어 핸드셰이크라고 부른다.
SSL 핸드셰이크 프로세스
- 클라이언트가 서버에 보안 연결을 요청한다.
- 서버는 사용 방법을 알고 있는 암호 모음(cipher suites, 암호화된 연결을 만드는 알고리즘 툴 킷)을 제공한다.
- 클라이언트는 이 목록을 자신이 가지고 있는 암호 모음과 비교해 하나를 선택하고, 서버에 어던 모음을 사용할 것인지 알린다.
- 서버는 클라이언트에게 자신의 신원을 줄 서드파티 기관이 발급한 디지털 인증서를 제공한다.
- 디지털 인증서가 서버의 퍼블릭 암호화 키를 내포하고 있다.
- 클라이언트는 서버 인증서를 받아 그 진위를 확인한다.
- 클라이언트와 서버는 퍼블릭 키를 사용해 나머지 세션에서 커뮤니케이션 암호화에 사용할 세션키를 설정한다. 여러 기술이 사용될 수 있다.
- 클라이언트가 퍼블릭 키를 사용해 무작위 숫자를 암호화한 후 이를 서버에 보내 복호화하고, 양측이 이 무작위 숫자를 사용해 세션키를 설정할 수 있다.
- 서버와 클라이언트가 디피-핼맨 (Diffie-Hellman)키 교환 방식을 사용해 세션 키를 설정할 수도 있다.
세션 키는 중단 없는 단일 커뮤니케이션 세션에 대해서만 유효하다.
즉, 클라이언트와 서버 간 통신이 끊기면 통신을 다시 이어지기 위해 핸드 셰이크 프로세스를 다시 시작하여 새로운 세션을 만든다.
SSL은 여러 유형이 있다.
- 단일 도메인 : 단 하나의 도메인에만 적용 되는 SSL
- 와일드카드 : 도메인의 하위 도메인까지 포함되는 SSL
- 멀티 도메인 : 관련되지 않은 다수의 도메인에 적용가능 한 SSL
SSL 인증서란?
SSL 인증서는 안전한 연결을 시작하는 데 필요한 퍼블릭 암호화 키를 클라이언트에 제공한다.
인증서는 퍼블릭 키 뿐만 아니라, 그것을 제공하는 단체와 관련있음을 클라이언트에 알려주는 역할도 한다.
도메인을 구매했으면, 등록하고자 하는 인증서 서버에 도메인을 연결하고,
그 인증서 서버는 도메인에 대해 인증하고 있음을 알려준다.
이를 통해 중간자 공격을 예방할 수 있다.
TLS과 OSI 7계층
- SSL은 다양한 어플리케이션들을 지원하기 위해 각각의 응용된 어플리케이션 프로토콜을 가진다.
- SSL은 OSI 7 계층에서 5 계층인 Session Layer에 속하며, 지원 가능한 프로토콜은 어플리케이션 레이어 상에 위한 하부 프로토콜로 한정될 수 밖에 없는데 HTTP, IMAP, FTP, NNTP 등이다.
TLS HandsShake Protocol 동작원리
- 먼저 클라이언트에서 서버에 ClientHello 메시지를 보낸다. 여기에는 클라이언트에서 가능한 TLS 버전, 서버 도메인, 세션 식별자, 암호 설정 등의 정보가 포함된다.
- 클라이언트의 메시지를 받은 서버는 ServerHello 메시지를 클라이언트에게 보낸다. 여기에는 ClientHello 메시지의 정보 중 서버에서 사용하기로 선택한 TLS 버전, 세션 식별자, 암호 설정 등의 정보가 포함된다.
- 서버가 클라이언트에 Certificate 메시지를 보낸다. 여기에는 서버의 인증서가 들어간다. 이 인증서는 별도의 인증 기관에서 발급받은 것이며, 서버가 신뢰할 수 있는 자임을 인증한다. 전송이 끝나면 ServerHelloDone 메시지를 보내 끝났음을 알린다.
- 클라이언트는 서버에서 받은 인증서를 검증한다. 인증서의 유효 기간이 만료되지 않았는지, 그 인증서가 해당 서버에게 발급된 인증서가 맞는지 등을 확인한다. 인증서를 신뢰할 수 있다고 판단하였다면 다음 단계로 넘어간다.
- 클라이언트는 임의의 pre-master secret[1]을 생성한 뒤, 서버가 보낸 인증서에 포함된 공개 키를 사용해 암호화한다. 이렇게 암호화된 pre-master secret을 ClientKeyExchange 메시지에 포함시켜 서버에 전송한다.[2]
- 서버는 전송받은 정보를 복호화하여 pre-master secret을 알아낸 뒤, 이 정보를 사용해 master secret을 생성한다. 그 뒤 master secret에서 세션 키를 생성해내며, 이 세션 키는 앞으로 서버와 클라이언트 간의 통신을 암호화하는데 사용될 것이다. 물론 클라이언트 역시 자신이 만들어낸 pre-master secret을 알고 있으므로, 같은 과정을 거쳐 세션 키를 스스로 만들 수 있다.
- 이제 서버와 클라이언트는 각자 동일한 세션 키를 가지고 있으며, 이 키를 사용해 대칭키 암호를 사용하는 통신을 할 수 있다. 따라서 우선 서로에게 ChangeCipherSpec 메시지를 보내 앞으로의 모든 통신 내용은 세션 키를 사용해 암호화해 보낼 것을 알려준 뒤, Finished 메시지를 보내 각자의 핸드셰이킹 과정이 끝났음을 알린다.
- 이제 서버와 클라이언트 간에 보안 통신이 구성된다.
TLS Recode Layer
- In SSL Record Protocol 데이터는 fragment 단위로 쪼개진다.
- fragment는 옵션으로 압축을 할 수 있으며 최초 TLS Connection을 맺을 때 생성한 대칭키로 암호화 된다.
- fragment의 암호화가 완료되면 SSL header정보가 data에 추가된다.
그렇다면 인증기관은 어디에?
크롬 설정 → 개인정보 및 보안 → 인증서 관리
HTTP에서 HTTPS로 리다이렉트
- tomcat 설정 server.xml 으로 제어
- web.xml 설정으로 제어
참고
https://www.cloudflare.com/ko-kr/learning/ssl/what-is-ssl/
https://www.itworld.co.kr/news/113007
'개발' 카테고리의 다른 글
| 프론트엔드 개발에 대한 고찰 - 아키텍처 관점 (2) | 2024.12.22 |
|---|