HTTPS Everywhere is a Firefox and Chrome extension that encrypts your communications with many major...
HTTPS
From Wikipedia, the free encyclopedia
HTTPS (also called
HTTP over TLS,
[1][2] HTTP over SSL,
[3] and
HTTP Secure[4][5]) is a
protocol for
secure communication over a
computer network which is widely used on the
Internet. HTTPS consists of communication over
Hypertext Transfer Protocol (HTTP) within a connection encrypted by
Transport Layer Security or its predecessor, Secure Sockets Layer. The main motivation for HTTPS is
authentication of the visited
website and protection of the
privacy and
integrity of the exchanged data.
In its popular deployment on the internet, HTTPS provides authentication of the website and associated
web server with which one is communicating, which protects against
man-in-the-middle attacks. Additionally, it provides bidirectional
encryption of communications between a client and server, which protects against
eavesdropping and
tampering with or forging the contents of the communication.
[6]
In practice, this provides a reasonable guarantee that one is
communicating with precisely the website that one intended to
communicate with (as opposed to an impostor), as well as ensuring that
the contents of communications between the user and site cannot be read
or forged by any third party.
Historically, HTTPS connections were primarily used for payment transactions on the
World Wide Web,
e-mail and for sensitive transactions in corporate information systems.
In the late 2000s and early 2010s, HTTPS began to see widespread use
for protecting page authenticity on all types of websites, securing
accounts and keeping user communications, identity and
web browsing private.
Overview
Logo of the networking protocol https and the www letters
The
HTTPS uniform resource identifier
(URI) scheme has identical syntax to the standard HTTP scheme, aside
from its scheme token. However, HTTPS signals the browser to use an
added encryption layer of SSL/TLS to protect the traffic. 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 creates a secure channel over an insecure network. This ensures reasonable protection from
eavesdroppers and
man-in-the-middle attacks, provided that adequate
cipher suites are used and that the server certificate is verified and trusted.
Because HTTPS piggybacks HTTP entirely on top of TLS, the entirety of
the underlying HTTP protocol can be encrypted. This includes the
request URL (which particular web page was requested), query parameters,
headers, and cookies (which often contain identity information about
the user). However, because host (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 (sometimes even
the domain name e.g. www.example.org, but not the rest of the URL) that
one is communicating with as well as the amount (data transferred) and
duration (length of session) of the communication, though not the
content of the communication.
[6]
Web browsers know how to trust HTTPS websites based on
certificate authorities that come pre-installed in their software. Certificate authorities (such as
Symantec,
Comodo,
GoDaddy and
GlobalSign)
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 the browser software correctly implements HTTPS with correctly pre-installed certificate authorities.
- The user trusts the certificate authority to vouch only for legitimate websites.
- 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 is especially important over insecure networks (such as public
WiFi access points), as anyone on the same local network can
packet sniff
and discover sensitive information not protected by HTTPS.
Additionally, many free to use and even paid for WLAN networks engage in
packet injection
in order to serve their own ads on webpages. However, this can be
exploited maliciously in many ways, such as injecting malware onto
webpages and stealing users' private information.
[7]
HTTPS is also very important for connections over the
Tor anonymity network,
as malicious Tor nodes can damage or alter the contents passing through
them in an insecure fashion and inject malware into the connection.
This is one reason why the
Electronic Frontier Foundation and the Tor project started the development of
HTTPS Everywhere,
[6] which is included in the Tor Browser Bundle.
[8]
As more information is revealed about global
mass surveillance
and criminals stealing personal information, the use of HTTPS security
on all websites is becoming increasingly important regardless of the
type of Internet connection being used.
[9][10] While
metadata
about individual pages that a user visits is not sensitive, when
combined together, they can reveal a lot about the user and compromise
the user's privacy.
[2][11][12]
Deploying HTTPS also allows the use of
SPDY/
HTTP/2, that are new generations of HTTP, designed to reduce page load times and latency.
It is recommended to use
HTTP Strict Transport Security (HSTS) with HTTPS to protect users from man-in-the-middle attacks, especially
SSL stripping.
[12][13]
HTTPS should not be confused with the little-used
Secure HTTP (S-HTTP) specified in
RFC 2660.
Usage in websites
As of June 28, 2016, 10.2% of Alexa top 1,000,000 websites use HTTPS as default.
[14]
As of June 1, 2016, 43.1% of the Internet's 141,387 most popular websites have a secure implementation of HTTPS.
[15]
Browser integration
Most
browsers display a warning if they receive an invalid certificate.
Older browsers, when connecting to a site with an invalid certificate,
would present the user with a dialog box asking if they wanted to
continue. Newer browsers display a warning across the entire window.
Newer browsers also prominently display the site's security information
in the
address bar.
Extended validation certificates
turn the address bar green in newer browsers. Most browsers also
display a warning to the user when visiting a site that contains a
mixture of encrypted and unencrypted content.
Comparison between different kinds of SSL/TLS certificates
(Using Firefox as an example) |
|
|
Many web browsers, including Firefox (shown here), use the address bar to tell the user that their connection is secure, often by coloring the background. |
|
|
When accessing a site only with a common certificate, the address bar of Firefox turns green. For some other browsers, a "lock" sign may appear. |
|
|
Most web browsers alert the user when visiting sites that have invalid security certificates.
|
|
Firefox uses HTTPS for Google searches as of version 14,
[16]
to "shield our users from network infrastructure that may be gathering
data about the users or modifying/censoring their search results".
[17]
The
Electronic Frontier Foundation, opining that "In an ideal world, every web request could be defaulted to HTTPS", has provided an add-on called
HTTPS Everywhere for
Mozilla Firefox that enables HTTPS by default for hundreds of frequently used websites. A beta version of this plugin is also available for
Google Chrome and Chromium.
[18][19]
Security
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 client and
server.
X.509 certificates are used to authenticate the server (and sometimes the client as well). As a consequence,
certificate authorities and
public key certificates
are necessary to verify the relation between the certificate and its
owner, as well as to generate, sign, and administer the validity of
certificates. While this can be more beneficial than verifying the
identities via a
web of trust, the
2013 mass surveillance disclosures drew attention to certificate authorities as a potential weak point allowing
man-in-the-middle attacks.
[20][21] 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.
[22][needs update]
A site must be completely hosted over HTTPS, without having part of
its contents loaded over HTTP - for example, having scripts loaded
insecurely - or the user will be vulnerable to some attacks and
surveillance. Also having only a certain page that contains sensitive
information (such as a log-in page) of a website loaded over HTTPS,
while having the rest of the website loaded over plain HTTP, will expose
the user to attacks. On a site that has sensitive information somewhere
on it, every time that site is accessed with HTTP instead of HTTPS, the
user and the session will get exposed. Similarly,
cookies on a site served through HTTPS have to have the
secure attribute enabled.
[12]
Technical
Difference from HTTP
HTTPS URLs begin with "https://" and use
port 443 by default, whereas
HTTP URLs begin with "http://" and use
port 80 by default.
HTTP is not encrypted and is vulnerable to man-in-the-middle and
eavesdropping attacks, which can let attackers gain access to website
accounts and sensitive information, and modify webpages to inject
malware
or advertisements. HTTPS is designed to withstand such attacks and is
considered secure against them (with the exception of older, deprecated
versions of SSL).
Network layers
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 use of ordinary
HTTP over an
encrypted SSL/TLS connection.
Everything in the HTTPS message is encrypted, including the headers,
and the request/response load. With the exception of the possible
CCA cryptographic attack described in the
limitations
section below, the attacker can only know that a connection is taking
place between the two parties and their domain names and IP addresses.
Server setup
To prepare a web server to accept HTTPS connections, the administrator must create a
public key certificate for the web server. This certificate must be signed by a trusted
certificate authority
for the web browser to accept it without warning. The authority
certifies that the certificate holder is the operator of the web server
that presents it. Web browsers are generally distributed with a list of
signing certificates of major certificate authorities so that they can verify certificates signed by them.
Acquiring certificates
Authoritatively signed certificates may be free
[23][24] or cost between
8 USD[25] and
70 USD[26] per year (in 2012–2014).
Organizations may also run their own certificate authority,
particularly if they are responsible for setting up browsers to access
their own sites (for example, sites on a company
intranet,
or major universities). They can easily add copies of their own signing
certificate to the trusted certificates distributed with the browser.
There also exists a peer-to-peer certificate authority,
CACert.
However, it is not included in the trusted root certificates of many
popular browsers (e.g. Firefox, Chrome, Internet Explorer), which may
cause warning messages to be displayed to end users.
Let's Encrypt, launched in April 2016,
[27] provides free and automated SSL/TLS certificates to websites.
[28] According to the
Electronic Frontier Foundation, "Let's Encrypt" will make switching from HTTP to HTTPS "as easy as issuing one command, or clicking one button."
[29]
Use as access control
The system can also be used for client
authentication
in order to limit access to a web server to authorized users. To do
this, the site administrator typically creates a certificate for each
user, a certificate that is loaded into their browser. Normally, that
contains the name and e-mail address of the authorized user and is
automatically checked by the server on each reconnect to verify the
user's identity, potentially without even entering a password.
In case of compromised secret (private) key
An important property in this context is
perfect forward secrecy
(PFS). Possessing one of the long-term asymmetric secret keys used to
establish an HTTPS session should not make it easier to derive the
short-term session key to then decrypt the conversation, even at a later
time.
Diffie–Hellman key exchange (DHE) and
Elliptic curve Diffie–Hellman
key exchange (ECDHE) are in 2013 the only ones known to have that
property. Only 30% of Firefox, Opera, and Chromium Browser sessions use
it, and nearly 0% of Apple's Safari and Microsoft Internet Explorer
sessions.
[22] Among the larger internet providers, only Google supports PFS since 2011 (State of September 2013).
[citation needed]
A certificate may be revoked before it expires, for example because
the secrecy of the private key has been compromised. Newer versions of
popular browsers such as
Firefox,
[30] Opera,
[31] and
Internet Explorer on
Windows Vista[32] implement the
Online Certificate Status Protocol
(OCSP) to verify that this is not the case. The browser sends the
certificate's serial number to the certificate authority or its delegate
via OCSP and the authority responds, telling the browser whether or not
the certificate is still valid.
[33]
Limitations
SSL/TLS comes in two options, simple and mutual. The mutual version is more secure, but requires the user to install a personal
client certificate into their web browser in order to authenticate themselves.
[citation needed]
Whatever strategy is used (simple or mutual), the level of protection strongly depends on the correctness of the
implementation of the
web browser and the server software and the actual
cryptographic algorithms supported.
SSL/TLS does not prevent the entire site from being indexed using a
web crawler, and in some cases the
URI of the encrypted resource can be inferred by knowing only the intercepted request/response size.
[34] This allows an attacker to have access to the
plaintext (the publicly available static content), and the
encrypted text (the encrypted version of the static content), permitting a
cryptographic attack.
Because
TLS
operates below HTTP and has no knowledge of higher-level protocols, TLS
servers can only strictly present one certificate for a particular
IP/port combination.
[35] This means that, in most cases, it is 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 many older browsers do not support this
extension. Support for SNI is available since
Firefox 2,
Opera 8, Safari 2.1, Google Chrome 6, and
Internet Explorer 7 on
Windows Vista.
[36][37][38]
From an architectural point of view:
- An SSL/TLS connection is managed by the first front machine that
initiates the TLS connection. If, for any reasons (routing, traffic
optimization, etc.), this front machine is not the application server
and it has to decipher data, solutions have to be found to propagate
user authentication information or certificate to the application
server, which needs to know who is going to be connected.
- For SSL/TLS with mutual authentication, the SSL/TLS session is
managed by the first server that initiates the connection. In situations
where encryption has to be propagated along chained servers, session
timeOut management becomes extremely tricky to implement.
- With mutual SSL/TLS, security is maximal, but on the client-side,
there is no way to properly end the SSL/TLS connection and disconnect
the user except by waiting for the server session to expire or closing
all related client applications.
A sophisticated type of
man-in-the-middle attack
called SSL stripping was presented at the Blackhat Conference 2009.
This type of attack defeats the security provided by HTTPS by changing
the
https: link into an
http: link, taking advantage
of the fact that few Internet users actually type "https" into their
browser interface: they get to a secure site by clicking on a link, and
thus are fooled into thinking that they are using HTTPS when in fact
they are using HTTP. The attacker then communicates in clear with the
client.
[39] This prompted the development of a countermeasure in HTTP called
HTTP Strict Transport Security.
HTTPS has been shown vulnerable to a range of
traffic analysis attacks. Traffic analysis attacks are a type of
side-channel attack
that relies on variations in the timing and size of traffic in order to
infer properties about the encrypted traffic itself. Traffic analysis
is possible because SSL/TLS encryption changes the contents of traffic,
but has minimal impact on the size and timing of traffic. In May 2010, a
research paper by researchers from
Microsoft Research and
Indiana University
discovered that detailed sensitive user data can be inferred from side
channels such as packet sizes. More specifically, the researchers found
that an eavesdropper can infer the illnesses/medications/surgeries of
the user, his/her family income and investment secrets, despite HTTPS
protection in several high-profile, top-of-the-line web applications in
healthcare, taxation, investment and web search.
[40]
Although this work demonstrated vulnerability of HTTPS to traffic
analysis, the approach presented by the authors required manual analysis
and focused specifically on web applications protected by HTTPS.
In June 2014, a team of researchers at
UC Berkeley and
Intel lead by
Brad Miller demonstrated a generalized approach to HTTPS traffic analysis based on
machine learning.
[41][42] The researchers demonstrated that the attack applied to a range of websites, including
Mayo Clinic,
Planned Parenthood and
Youtube.
[43]
The attack assumes that the attacker is able to visit the same webpages
as the victim to gather network traffic which serves as training data.
The attacker is then able to identify similarities in the packet sizes
and orderings between the victim traffic and the training data traffic
which frequently allow the attacker to infer the exact page the victim
is visiting. For example, this attack could be used to determine whether
a user browsing the Planned Parenthood website is looking for
information about preventative health screening or an abortion. Note
that the attack can not be used to discover user specific values
embedded in a webpage. For example, many banks offer web interfaces
which allow users to view account balances. While the attacker would be
able to discover that the user was viewing an account balance page, he
would be unable to learn the users exact account balance or account
number.
History
Netscape Communications created HTTPS in 1994 for its
Netscape Navigator web browser.
[44] Originally, HTTPS was used with the
SSL protocol. As SSL evolved into
Transport Layer Security (TLS), the current version of HTTPS was formally specified by
RFC 2818 in May 2000.
See also
References
Many web browsers, including Firefox (shown here), use the address bar to tell the user that their connection is secure, often by coloring the background.
Most web browsers alert the user when visiting sites that have invalid security certificates.
1 comment:
Thanks for giving detailed Explanation on HTTPS. I learned much more in this than Wikipedia, It's the core of single with complete actions. Keep going!
Post a Comment