번역 작업 진행중입니다.

초안
이 문서는 작성중입니다.

 TLS(Transport Layer Security)를 사용하는 연결의 보안은 암호 스위트(Ciper Suites)와 선택된 보안 파라메터에 과하게 의존합니다. 이 문서는 클라이언트와 서버 사이의 기밀성과 무결성 통신을 보장하기 위한 결정을 하도록 돕는 것이 목적입니다. 모질라 운영 보안(OpSec) 팀은 서버를 위한 참조용 설정이 있는 위키를 관리합니다..

 TLS(Transport Layer Security) 프로토콜은 네트워크로 연결된 두 개의 어플리케이션 혹은 디바이스가 비밀스럽고 강건하게 정보를 교환하도록 하는 표준입니다. TLS를 사용하는 어플리케이션은 데이터의 보안과 신뢰성에 상당한 영향을 미칠 수 있는 보안 파라메터를 선택할 수 있습니다. 이 글은 TLS에 대한 개요와 컨텐츠를 보호할 때 필요한 결정을 제공합니다. 

역사

 HTTPS가 처음 발표 됐을 때는 넷스케이프가 도입한 기술인 SSL(Secure Sockets Layer) 2.0에 기반을 뒀습니다. 얼마되지 않아 SSL이 3.0으로 업데이트 되고 사용처가 확대되면서, 모든 웹 브라우저와 서버 사이에 상호 운영성을 보장하기 위한 공통의 표준 암호화 기술이 지정해야 하는 것이 명확해졌습니다. 국제 인터넷 표준화 기구(IETF)는 1999년 1월, TLS 1.0 RFC 2246을 지정했습니다. 현재 TLS의 버전은 1.2 RFC 5246입니다. 프로토콜에 대한 주요 개정 작업이 진행중이며, TLS 1.3이 거의 완성됐습니다.

이제 웹이 암호화에 TLS를 사용하고 있음에도 불구하고, 많은 사람들이 아직까지 습관적으로 TLS를 "SSL"이라고 언급합니다.  

 TLS가 저-수준의 전송 프로토콜의 맨 위에서 사용될 수 있지만, 이 프로토콜은 원래 HTTP 트래픽을 암호화하는 것이 목적이었습니다. TLS로 암호화된 HTTP는 흔히 HTTPS라고 언급됐습니다. TLS로 암호화된 웹 트래픽은 관습적으로 443 포트 위에서 교환되었으며, 암호화되지 않은 HTTP는 기본적으로 80번 포트를 사용합니다. HTTPS는 중요한 TLS 사용 사례로 남았습니다.

TLS위의 HTTP

TLS는 주고받는 데이터의 안전과 보안을 보장하게 하는 세 가지 주요 서비스를 제공합니다. 

인증
Authentication lets each party to the communication verify that the other party is who they claim to be.
암호화
Data is encrypted while being transmitted between the user agent and the server, in order to prevent it from being read and interpreted by unauthorized parties.
무결성
TLS ensures that between encrypting, transmitting, and decrypting the data, no information is lost, damaged, tampered with, or falsified.

A TLS connection starts with a handshake phase where a client and server agree on a shared secret and important parameters, like cipher suites, are negotiated. Once parameters and a data exchange mode where application data, such HTTP, is exchanged.

Cipher suites

The primary parameters that the TLS handshake negotiates is a cipher suite.

In TLS 1.2 and earlier, the negotiated cipher suite includes a set of cryptographic algorithms that together provide the negotiation of the shared secret, the means by which a server is authenticated, and the method that will be used to encrypt data.

The cipher suite in TLS 1.3 primarily governs the encryption of data, separate negotiation methods are used for key agreement and authentication.

Different software might use different names for the same cipher suites. For instance, the names used in OpenSSL and GnuTLS differ from those in the TLS standards. The cipher names correspondence table on the Mozilla OpSec team's article on TLS configurations lists these names as well as information about compatibility and security levels.

Configuring your server

Correctly configuring your server is crucial. In general, you should try to limit cipher support to the newest ciphers possible which are compatible with the browsers you want to be able to connect to your site. The Mozilla OpSec guide to TLS configurations provides more information on recommended configurations.

To assist you in configuring your site, Mozilla provides a helpful TLS configuration generator that will generate configuration files for the following Web servers:

  • Apache
  • Nginx
  • Lighttpd
  • HAProxy
  • Amazon Web Services CloudFormation Elastic Load Balancer

Using the configurator is a recommended way to create the configuration to meet your needs; then copy and paste it into the appropriate file on your server and restart the server to pick up the changes. The configuration file may need some adjustments to include custom settings, so be sure to review the generated configuration before using it; installing the configuration file without ensuring any references to domain names and the like are correct will result in a server that just doesn't work.

TLS 1.3

RFC 8446: TLS 1.3 is a major revision to TLS. TLS 1.3 includes numerous changes that improve security and performance. The goals of TLS 1.3 are:

  • Remove unused and unsafe features of TLS 1.2.
  • Include strong security analysis in the design.
  • Improve privacy by encrypting more of the protocol.
  • Reduce the time needed to complete a handshake.

TLS 1.3 changes much of the protocol fundamentals, but preserves almost all of the basic capabilities as previous versions of TLS. For the web, TLS 1.3 can be enabled without affecting compatibility with some rare exceptions (see below).

The major changes in TLS 1.3 are:

  • The TLS 1.3 handshake completes in one round trip in most cases, reducing handshake latency.
  • A server can enable a 0-RTT (zero round trip time) handshake. Clients that reconnect to the server can send requests immediately, eliminating the latency of the TLS handshake entirely. Though the performance gains from 0-RTT can be significant, they come with some risk of replay attack, so some care is needed before enabling this feature.
  • TLS 1.3 supports forward-secure modes only, unless the connection is resumed or it uses a pre-shared key.
  • TLS 1.3 defines a new set of cipher suites that are exclusive to TLS 1.3. These cipher suites all use modern Authenticated Encryption with Associated Data (AEAD) algorithms.
  • The TLS 1.3 handshake is encrypted, except for the messages that are necessary to establish a shared secret. In particular, this means that server and client certificates are encrypted. Note however that the server identity (the server_name or SNI extension) that a client sends to the server is not encrypted.
  • Numerous mechanisms have been disabled: renegotiation, generic data compression, Digital Signature Algorithm (DSA) certificates, static RSA key exchange, and key exchange with custom Diffie-Hellman (DH) groups.

Implementations of draft versions of TLS 1.3 are available. TLS 1.3 is enabled in some browsers, including the 0-RTT mode. Web servers that enable TLS 1.3 might need to adjust configuration to allow TLS 1.3 to operate successfully.

TLS 1.3 adds just one significant new use case. The 0-RTT handshake can provide significant performance gains for latency sensitive applications, like the web. Enabling 0-RTT requires additional steps, both to ensure successful deployment and to manage the risks of replay attacks.

The removal of renegotiation in TLS 1.3 might affect some web servers that rely on client authentication using certificates. Some web servers use renegotiation to either ensure that client certificates are encrypted, or to request client certificates only when certain resources are requested. For the privacy of client certificates, the encryption of the TLS 1.3 handshake ensures that client certificates are encrypted; however this might require some software changes. Reactive client authentication using certificates is supported by TLS 1.3 but not widely implemented. Alternative mechanisms are in the process of being developed, which will also support HTTP/2.

TLS handshake timeout values

If the TLS handshake starts to become slow or unresponsive for some reason, the user's experience can be affected significantly. To mitigate this problem, modern browsers have implemented handshake timeouts:

  • Since version 58, Firefox implements a TLS handshake timeout with a default value of 30 seconds. The timeout value can be varied by editing the network.http.tls-handshake-timeout pref in about:config.

See also

문서 태그 및 공헌자

이 페이지의 공헌자: haeguri
최종 변경자: haeguri,