The HTTPS protocol uses TLS to secure web communication. It is also called "HTTP over TLS", or even more commonly "that little lock symbol on your browser". The lock symbol is not the only clue a website is using HTTPS to communicate, the URL also begins with "https://". Most web communications take place on port 80, while HTTPS traffic is sent over port 443.
HTTPS is most widely know for and used for e-commerce and online payments, but is is quickly standard practice in many other contexts because of the privacy and data integrity advantages it offers. (See the guide on SSL and TLS for details.) Many services now offer "HTTPS-only" as a user-configurable preference, while others are making HTTPS automatic and mandatory. Beginning in August 2014, Google Search began including HTTPS as a rank-increasing attribute in tallying website rankings. One survey reports that, as of June 2016, 43% of most popular websites use HTTPS.
There has been a recent push for making HTTPS a standard feature of all websites. The Electronic Frontier Foundation (EFF) has launched a campaign called "HTTPS Everywhere" to advocate for encrypting all web communications with TLS. Another related effort called "Let's Encrypt" offers free certificates signed by certificate authority. In March 2016, Semantic, one of the largest issuers of certificates for HTTPS, launched an "Encryption Everywhere" program which offers free certificates.
HTTPS uses TLS, which requires a public key to begin communication. HTTPS uses a Public-Key Certificate, often referred to as an "SSL certificate" or "SSL cert"(even though it does not use SSL anymore) to prove ownership of a public key. It validates the authenticity of the public key so that a user can recognize and trust digital signatures made using the private key which matches this public key. The certificate itself is comprised of the public key, information about the owner of the public key, a certificate start and expiration date, and the digital signature of a Certificate Authority (CA). The CA signature indicates that someone reputable has vouched for this key and other information. It also ensures that the public key has not been modified.
To set up a server for HTTPS, the server administrator creates a Certificate Signing Request (CSR) which is the combination of a public key and some basic information about the organization requesting the certificate. The administrator sends the CSR (along with any fees) to a Certificate Authority (CA). The CAs role is to validate the website making the request by verifying their identity and performing a basic background check for a history of fraud, phishing, or other red flags. Then the CA issues the administrator a Public-Key Certificate for the website. The administrator installs the certificate on the web server and adds configuration information to link all activity on port 443 to the Public-Key Certificate. Going forward, when a browser requests a URL using "https://", the request will be sent to port 443 on the server, the configuration will find the Public-Key Certificate, and an HTTPS connection will be established.
Web browser trust CA-signed certificates because they have been pre-installed with a list of trusted certificate authorities, such as Comodo, Semantic/Verisign, GoDaddy, GlobalSign, IdenTrust, and DigiCert. Browsers display "the little lock symbol" if a certificate domain matches the current domain, has been signed by a trusted CA, and is still within the start and expiration dates. They will display warnings on invalid or self-signed certificates that ask the user if they are sure they want to trust the certificate before proceeding.
The role of the Certificate Authority is to very the relationship between a public key and its owner. It does not guarantee more than this. It does not vouch for the owner's integrity, the health of their business, or their past business practices. It simply asserts that the owner owns the domain name, owns this public key, and did not raise any red flags during a brief background check.
CA background checks were once a rigorous process and required providing many business documents as proof of identity. Certificates were also expensive, in part due to the labor-intensive background checks. Over time and as certificate became more popular, they became less expensive—typically costing $10-70 per year, and quickly becoming entirely free— the background checks became much more lax. The basic requirement for proof of identify in most cases has now been reduced to being capable of receiving a verification email at an address on the same domain which sounds official (admin@somesite.com, webmaster@somesite.com, etc.).
This lower threshold of identify verification has opened the door to a number of vulnerabilities in the CA validation process. Attackers can easily get certificates signed by CAs. Many attackers use public-key certificates because it makes the sites they use for malicious purposes such as phishing seem legitimate. A user does not notice who owns a certificate, they only notice that a server has a certificate. Users trust "the little lock symbol" a little too much. An attacker can go through the normal CSR process for their domains or, if they can gain control of an official-sounding email address on another domain, they can get a certificate issued on a domain they do not even own.
Certificate authorities also offer Extended Validation (EV) Certificates. EV certificates are a result of the lower fees and increasingly lax verifications on regular certificates, and in many ways, they resemble the public-key certificates of old. For EV certificates, the CA performs more rigorous background checks and the certificates costs more money per year to obtain. EV certificates are noticably different to users because they turn the browser address bar green and display the official company name. EV certificates are sometimes required by credit card companies, usually based on the dollar amount of payments which will be accepted. It is debatable if EV certificates add any more security to the process. Certificate authorities would like customers to believe they are important because they generate higher fees. But an EV certificate will use the same pubic-key and same encryption; it just indicates that they business has gone through a more rigorous identify verification. Studies have shown the users do not understand the differences or care if their address bar is green (they only look for "the little lock"). And in several instances, attackers have been able to get EV certificates despite the promise of better identify validation.
Certificates do not need to be signed by a Certificate Authority to be valid. It can be self-signed instead. A self-signed certificate verifies that the public key is legitimate and has not be altered. It simply does not make a third-party representation to the identity of the organization who generated the public-key. Self-signed certificates are used when two parties already trust each other's identities. Self-signed certificates are commonly used for an organizations's internal servers.
