https

HTTPS(Hypertext Transfer Protocol Secure)란 무엇인가?

HTTPS는 HTTP에 암호화를 더한 보안 버전이다. 일반 HTTP가 엽서처럼 내용이 노출될 수 있다면, HTTPS는 밀봉된 등기우편처럼 제3자가 내용을 엿볼 수 없게 TLS(또는 이전의 SSL) 암호화로 보호한다.

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It uses encryption for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL.

TCP/IP 모델에서 TLS는 어느 계층에서 동작하며, HTTP 메시지를 어떻게 처리하는가?

TLS는 HTTP와 같은 응용 계층에서 동작하며, HTTP 메시지를 보내기 전에 암호화하고 받을 때 복호화한다. HTTPS는 별도의 프로토콜이 아니라, 기존 HTTP 통신을 암호화된 TLS 터널 안에서 수행하는 것이다.

HTTP operates at the highest layer of the TCP/IP model—the application layer; as does the TLS security protocol (operating as a lower sublayer of the same layer), which encrypts an HTTP message prior to transmission and decrypts a message upon arrival. Strictly speaking, HTTPS is not a separate protocol, but refers to the use of ordinary HTTP over an encrypted SSL/TLS connection. HTTPS encrypts all message contents, including the HTTP headers and the request/response data.

HTTPS가 해결하는 보안 문제는 무엇이며, 어떤 메커니즘으로 보호하는가?

HTTPS는 세 가지를 보호한다. 접속한 사이트가 진짜인지 확인(인증), 주고받는 데이터를 제3자가 엿보지 못하게 보호(기밀성), 데이터가 전송 중에 변조되지 않았음을 보장(무결성)한다.

The principal motivations for HTTPS are authentication of the accessed website and protection of the privacy and integrity of the exchanged data while it is in transit. It protects against man-in-the-middle attacks, and the bidirectional block cipher encryption of communications between a client and server protects the communications against eavesdropping and tampering.

HTTPS 인증에 신뢰할 수 있는 제3자(trusted third party)가 필요한 이유와, 이것이 HTTPS 초기 보급을 제한한 원인은?

HTTPS는 인증서 발급 기관(CA)이라는 신뢰할 수 있는 제3자가 "이 사이트는 진짜"라고 보증해주어야 한다. 과거에는 인증서 비용이 높아 결제 페이지 등 일부에만 사용했지만, 2016년 이후 무료 인증서 보급이 확산되며 대부분의 사이트가 HTTPS를 채택했다.

The authentication aspect of HTTPS requires a trusted third party to sign server-side digital certificates. This was historically an expensive operation, which meant fully authenticated HTTPS connections were usually found only on secured payment transaction services and other secured corporate information systems on the World Wide Web. In 2016, a campaign by the Electronic Frontier Foundation with the support of web browser developers led to the protocol becoming more prevalent. HTTPS has since 2018 been used more often by web users than non-secure HTTP, primarily to protect page authenticity on all types of websites, secure accounts, and keep user communications, identity, and web browsing private.

HTTPS는 HTTP의 어떤 부분을 암호화하고, 어떤 정보는 보호하지 못하는가?

HTTPS는 URL, 쿼리 파라미터, 헤더, 쿠키 등 HTTP 메시지 전체를 암호화한다. 하지만 접속하는 서버의 IP 주소, 포트 번호, 그리고 경우에 따라 도메인 이름은 네트워크 연결 자체에 필요하므로 노출될 수 있다.

Because HTTPS piggybacks HTTP entirely on top of TLS, the entirety of the underlying HTTP protocol can be encrypted. This includes the request's URL, query parameters, headers, and cookies (which often contain identifying information about the user). However, because website addresses and port numbers are necessarily part of the underlying TCP/IP protocols, HTTPS cannot protect their disclosure. In practice this means that even on a correctly configured web server, eavesdroppers can infer the IP address and port number of the web server, and sometimes even the domain name (e.g. www.example.org, but not the rest of the URL) that a user is communicating with, along with the amount of data transferred and the duration of the communication, though not the content of the communication.

웹에서 TLS 인증은 보통 어느 한쪽만 수행되는데, 어느 쪽이 인증되며 그 이유는?

일반적인 웹 통신에서는 서버만 인증된다. 사용자(클라이언트)는 브라우저가 서버의 인증서를 검사해 "이 사이트가 진짜 맞는지" 확인하지만, 서버가 사용자를 인증하는 것은 별도의 로그인 과정으로 처리한다.

SSL/TLS is especially suited for HTTP, since it can provide some protection even if only one side of the communication is authenticated. This is the case with HTTP transactions over the Internet, where typically only the server is authenticated (by the client examining the server's certificate).

사용자가 HTTPS 연결을 신뢰할 수 있으려면 어떤 전제조건이 충족되어야 하는가?

HTTPS를 신뢰하려면 여러 전제가 필요하다. 사용자의 기기와 브라우저가 안전하고, 브라우저에 내장된 인증 기관이 신뢰할 만하며, 해당 사이트의 인증서가 유효하고, 암호화 자체가 충분히 강력해야 한다. 이 중 하나라도 깨지면 보안이 무너질 수 있다.

Web browsers know how to trust HTTPS websites based on certificate authorities that come pre-installed in their software. Certificate authorities are in this way being trusted by web browser creators to provide valid certificates. Therefore, a user should trust an HTTPS connection to a website if and only if all of the following are true: The user trusts that their device, hosting the browser and the method to get the browser itself, is not compromised (i.e. there is no supply chain attack). The user trusts that the browser software correctly implements HTTPS with correctly pre-installed certificate authorities. The user trusts the certificate authority to vouch only for legitimate websites (i.e. the certificate authority is not compromised and there is no mis-issuance of certificates). The website provides a valid certificate, which means it was signed by a trusted authority. The certificate correctly identifies the website (e.g., when the browser visits "https://example.com", the received certificate is properly for "example.com" and not some other entity). The user trusts that the protocol's encryption layer (SSL/TLS) is sufficiently secure against eavesdroppers.

HTTPS가 공용 와이파이 같은 안전하지 않은 네트워크에서 특히 중요한 이유는?

카페나 공항의 공용 와이파이에서는 같은 네트워크에 있는 누구나 다른 사람의 데이터를 엿볼 수 있다. HTTPS가 없으면 비밀번호, 개인정보 등이 그대로 노출되며, 일부 네트워크는 웹페이지에 광고나 악성코드를 삽입하기도 한다.

HTTPS is especially important over insecure networks and networks that may be subject to tampering. Insecure networks, such as public Wi-Fi access points, allow anyone on the same local network to packet-sniff and discover sensitive information not protected by HTTPS. Additionally, some free-to-use and paid WLAN networks have been observed tampering with webpages by engaging in packet injection in order to serve their own ads on other websites. This practice can be exploited maliciously in many ways, such as by injecting malware onto webpages and stealing users' private information.

HTTPS가 보안 외에 성능에도 영향을 미치는 이유는?

HTTPS를 적용하면 HTTP/2, HTTP/3 같은 최신 프로토콜을 사용할 수 있게 되는데, 이 프로토콜들은 페이지 로딩 속도를 크게 개선한다. 즉 보안뿐 아니라 성능 향상의 전제 조건이기도 하다.

Deploying HTTPS also allows the use of HTTP/2 and HTTP/3 (and their predecessors SPDY and QUIC), which are new HTTP versions designed to reduce page load times, size, and latency.

HSTS(HTTP Strict Transport Security)란 무엇이며, 어떤 공격을 방어하는가?

HSTS는 브라우저에게 "이 사이트는 항상 HTTPS로만 접속하라"고 지시하는 보안 정책이다. 공격자가 사용자를 HTTP로 강제 전환시켜 암호화를 무력화하는 SSL 스트리핑 공격을 방어한다.

It is recommended to use HTTP Strict Transport Security (HSTS) with HTTPS to protect users from man-in-the-middle attacks, especially SSL stripping.

TLS가 데이터를 암호화하는 과정에서 장기 키와 세션 키의 역할은?

장기 키(공개키/개인키)는 서버의 신원을 확인하고 안전하게 임시 세션 키를 교환하는 데 사용된다. 실제 데이터 암호화는 이 세션 키로 수행한다. 신분증으로 본인을 확인한 뒤, 일회용 비밀번호로 대화하는 것과 비슷하다.

The security of HTTPS is that of the underlying TLS, which typically uses long-term public and private keys to generate a short-term session key, which is then used to encrypt the data flow between the client and the server. X.509 certificates are used to authenticate the server (and sometimes the client as well).

Forward secrecy란 무엇이며, 이것이 없으면 어떤 위험이 있는가?

Forward secrecy는 서버의 장기 키가 나중에 유출되더라도, 과거에 주고받은 암호화된 통신은 해독할 수 없도록 보장하는 속성이다. 이 속성이 없으면 공격자가 과거 통신을 저장해두었다가 키 유출 시 한꺼번에 복호화할 수 있다.

An important property in this context is forward secrecy, which ensures that encrypted communications recorded in the past cannot be retrieved and decrypted should long-term secret keys or passwords be compromised in the future. Not all web servers provide forward secrecy.

HTTPS 사이트에서 일부 콘텐츠만 HTTP로 로드되면 어떤 문제가 발생하며, 쿠키의 secure 속성은 왜 필요한가?

HTTPS 사이트라도 이미지나 스크립트 하나를 HTTP로 불러오면 그 부분은 암호화되지 않아 보안에 구멍이 생긴다. 쿠키에 secure 속성을 설정해야 HTTPS 연결에서만 쿠키가 전송되어, HTTP로 우회 접속 시 쿠키가 탈취되는 것을 막을 수 있다.

For HTTPS to be effective, a site must be completely hosted over HTTPS. If some of the site's contents are loaded over HTTP (scripts or images, for example), or if only a certain page that contains sensitive information, such as a log-in page, is loaded over HTTPS while the rest of the site is loaded over plain HTTP, the user will be vulnerable to attacks and surveillance. Additionally, cookies on a site served through HTTPS must have the secure attribute enabled. On a site that has sensitive information on it, the user and the session will get exposed every time that site is accessed with HTTP instead of HTTPS.

인증서가 만료 전에 무효화(revoke)되어야 할 때, 브라우저는 인증서의 유효 상태를 어떻게 확인하는가?

개인키가 유출되는 등의 이유로 인증서를 만료 전에 폐기해야 할 때, 브라우저는 OCSP라는 프로토콜로 인증 기관에 "이 인증서 아직 유효한가?"를 실시간 조회한다. 인증 기관은 폐기된 인증서 목록(CRL)을 별도로 배포하기도 한다.

A certificate may be revoked before it expires, for example because the secrecy of the private key has been compromised. The browser sends the certificate's serial number to the certificate authority or its delegate via OCSP (Online Certificate Status Protocol) and the authority responds, telling the browser whether the certificate is still valid or not. The CA may also issue a CRL to tell people that these certificates are revoked. CRLs are no longer required by the CA/Browser forum, nevertheless, they are still widely used by the CAs.

TLS 서버가 하나의 IP:포트 조합에 하나의 인증서만 제시할 수 있는 이유와, 이 제약을 SNI가 어떻게 해결하는가?

TLS는 HTTP보다 아래 계층에서 동작하므로 어떤 도메인에 접속하는지 모른 채 인증서를 제시해야 했다. SNI(Server Name Indication)는 암호화 연결을 맺기 전에 클라이언트가 접속할 도메인 이름을 먼저 알려주어, 하나의 IP에서 여러 도메인의 인증서를 구분할 수 있게 했다.

Because TLS operates at a protocol level below that of HTTP and has no knowledge of the higher-level protocols, TLS servers can only strictly present one certificate for a particular address and port combination. In the past, this meant that it was not feasible to use name-based virtual hosting with HTTPS. A solution called Server Name Indication (SNI) exists, which sends the hostname to the server before encrypting the connection, although older browsers do not support this extension.