문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 TLS (문단 편집) === 작동 방법 === [[인터넷]]을 사용한 통신에서 보안을 확보하려면 두 통신 당사자가 서로가 신뢰할 수 있는 자임을 확인할 수 있어야 하며, 서로간의 통신 내용이 제3자에 의해 도청되는 것을 방지해야 한다. 따라서 서로 자신을 신뢰할 수 있음을 알리기 위해 전자 서명이 포함된 인증서를 사용하며, 도청을 방지하기 위해 통신 내용을 암호화한다. 이러한 통신 규약을 묶어 정리한 것이 바로 TLS. 주요 웹브라우저 주소창에 자물쇠 아이콘이 뜨는 것으로 TLS의 적용 여부를 확인할 수 있다. 예를 들어 인터넷 뱅킹을 하기 위해 은행의 사이트에 방문했을 때, 고객은 그 사이트가 정말 은행의 사이트가 맞는지 아니면 해커가 만든 가짜 [[피싱]] 사이트인지 확인할 수 있어야 하며, 은행 역시 자신의 서비스에 접속한 자가 해당 고객이 맞는지 아니면 고객의 컴퓨터와 서버 사이에서 내용을 가로채고자 하는 해커인지 확인할 수 있어야 한다. 그리고 은행과 고객 간의 통신 내용이 다른 해커에게 도청되지 않도록 내용을 숨겨야 한다. 이럴 때 바로 은행과 고객 간에 TLS를 사용한 연결을 맺어 안전하게 통신할 수 있다. 구체적으로 서로의 신원을 확인하고 통신 암호화에 사용할 세션 키를 공유하기 위해 핸드셰이크(handshake) 과정을 거치며, 다음과 같다. 1. 먼저 클라이언트에서 서버에 ClientHello 메시지를 보낸다. 여기에는 클라이언트에서 사용 가능한 TLS 버전, 서버 도메인, 세션 식별자, 암호 설정 등의 정보가 포함된다. 1. 클라이언트의 메시지를 받은 서버는 ServerHello 메시지를 클라이언트에게 보낸다. 여기에는 ClientHello 메시지의 정보 중 서버에서 사용하기로 선택한 TLS 버전, 세션 식별자, 암호 설정 등의 정보가 포함된다. 1. 서버가 클라이언트에 Certificate 메시지를 보낸다. 여기에는 서버의 인증서가 들어간다. 이 인증서는 별도의 인증 기관에서 발급받은 것이며, 서버가 신뢰할 수 있는 자임을 인증한다. 전송이 끝나면 ServerHelloDone 메시지를 보내 끝났음을 알린다. 1. 클라이언트는 서버에서 받은 인증서를 검증한다. 인증서의 유효 기간이 만료되지 않았는지, 그 인증서가 해당 서버에게 발급된 인증서가 맞는지 등을 확인한다. 인증서를 신뢰할 수 있다고 판단하였다면 다음 단계로 넘어간다. 1. 클라이언트는 임의의 pre-master secret[* 세션 키를 생성해낼 '틀' 정도로 비유할 수 있겠다]을 생성한 뒤, 서버가 보낸 인증서에 포함된 공개 키를 사용해 암호화한다. 이렇게 암호화된 pre-master secret을 ClientKeyExchange 메시지에 포함시켜 서버에 전송한다.[* 이때 사용하는 암호화 알고리즘은 [[암호 알고리즘#비대칭형 암호|'''비대칭키''' 암호화 알고리즘]]으로 공개 키와 복호화 키가 따로 있으며, 공개 키로 암호화한 암호는 서버가 가지고 있는 복호화 키로만 풀 수 있다. 따라서 이때 메시지를 감청당하더라도 감청자는 복호키를 알 수 없으므로 pre-master secret을 알 수 없다. --클라이언트를 해킹하지만 않는다면-- 주로 [[RSA 암호화|RSA]]가 사용되지만 [[타원곡선]]서명(ECDSA) 등을 쓰는 경우도 있다. ] 1. 서버는 전송받은 정보를 복호화하여 pre-master secret을 알아낸 뒤, 이 정보를 사용해 master secret을 생성한다. 그 뒤 master secret에서 세션 키를 생성해내며, 이 세션 키는 앞으로 서버와 클라이언트 간의 통신을 암호화하는 데 사용될 것이다. 물론 클라이언트 역시 자신이 만들어낸 pre-master secret을 알고 있으므로, 같은 과정을 거쳐 세션 키를 스스로 만들 수 있다. 1. 이제 서버와 클라이언트는 각자 동일한 세션 키를 가지고 있으며, 이 키를 사용해 [[대칭키 암호]]를 사용하는 통신을 할 수 있다. 따라서 우선 서로에게 ChangeCipherSpec 메시지를 보내 앞으로의 모든 통신 내용은 세션 키를 사용해 암호화해 보낼 것을 알려준 뒤, Finished 메시지를 보내 각자의 핸드셰이킹 과정이 끝났음을 알린다. 1. 이제 서버와 클라이언트 간에 보안 통신이 구성된다. 경우에 따라 클라이언트에서 서버의 인증서를 요구하는 것뿐만 아니라 서버에서 클라이언트의 인증서를 요구하기도 한다. 쉽게 요약해서, 먼저 서로가 어떤 TLS 버전을 사용 가능한지를 확인하고, 인증서를 사용해 서로를 믿을 수 있는지 확인한 뒤, 서로간의 통신에 쓸 암호를 교환하는 것이다. 그 다음부터는 서로 교환한 암호를 사용해 제3자가 도청할 수 없는 암호화된 통신을 하면 된다. 이런 과정을 거쳐 가며 굳이 세션 자체에서 [[대칭키 암호]]를 쓰는 이유는, 비대칭키 암호화는 하드웨어 자원을 엄청나게 먹기 때문이다. 보안 수준 대비 준수한 속도를 내려면 대칭키를 쓸 수밖에 없다. 대칭 키 암호화 방식으로 과거에는 [[DES]], [[RC4]]나 심지어 [[SEED]]가 사용되는 경우도 있었으나, 현 시점에는 보안상 문제로 거의 퇴출되었으며 [[AES]]가 주류가 되었다. 대부분의 최신 CPU는 (모바일, PC, 서버를 막론하고) 암호화 연산의 하드웨어 가속을 지원하기 때문에, TLS를 적용하더라도 성능에 큰 영향을 받지 않는다. 하지만 암호화 하드웨어 가속 명령어가 탑재되지 않은 구형이나 저가형 프로세서에서는 간혹 성능 하락이 체감될 정도로 느려지는 경우도 있다. 때문에 이런 구형 기기에서도 효율적으로 암호화를 처리할 수 있도록 새로운 알고리즘 ChaCha20-Poly1305가 도입되었으며, 이는 TLS v1.2부터 지원한다. 2010년대 중반쯤 되면서 TLS의 비중이 높아지면서, 별별 물건이 나오고 있다. 공짜로 3개월치 인증서를 만들어주는 [[https://letsencrypt.org/|Let's Encrypt]][* [[티스토리]]에서는 개인 도메인을 연결하면 이걸 활용해서 TLS 연결을 만들어준다. 개인 도메인 연결하면 TLS 사용이 불가능한 걸로도 모자라 아예 개인 도메인 지원을 끊어버려는 [[네이버 블로그]]와 대조된다.]와 [[https://certbot.eff.org/|Certbot]], TLS 환경은 지원하나 기본적으로 연결되지 않는 페이지를 TLS로 연결시켜주는[* TLS가 불가능한 페이지를 TLS로 연결할 수는 없고(타 플러그인을 통해 강제로 TLS 접속을 시도해봐도 로딩이 불가능하다.), 그 대신 '암호화 되지 않은 모든 요청 차단'이라는 옵션을 통해 TLS 미지원 사이트와의 연결을 차단하게 할 수 있다.] [[https://www.eff.org/https-everywhere|HTTPS Everywhere]] 확장 기능이 그 예.저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기