What makes https more secure than http?
The short answer is that https communication between your browser and the server are encrypted. While http traffic is sent in plain text. This means that anyone who can listen to the traffic can read it - this would include usernames and passwords). It also verifies the server to which you are connecting.
That it is encrypted. Read: en.wikipedia.org/wiki/HTTP_Secure
Anything not over HTTPS can be read by anyone snooping on your network.
Im quoting:
Hypertext Transfer Protocol Secure (HTTPS) is a combination of the Hypertext Transfer Protocol with the SSL/TLS protocol to provide encryption and secure identification of the server.
More information on TLS:
The TLS protocol allows client/server applications to communicate across a network in a way designed to prevent eavesdropping and tampering. TLS provides endpoint authentication and communications confidentiality over the Internet using cryptography. TLS provides RSA security with 1024 and 2048 bit strengths.
Also, HTTPS verifies that the site is who it claims to be, if the certificates are correct (signed by a known CA).
All traffic is encrypted. No one on your network can see what is going on (except for knowing where those packets are going to).
The identity of the remote server can be verified using certificates. So you also know that it really is your bank that you are talking to.
Optionally (and not in wide-spread use), the identity of the client can also be verified using certificates. This would allow for secure login to a site using chip cards instead of (or in addition to) passwords.
I want to be really pedantic, as I'm a security nerd :)
HTTPS uses SSL, and it's IETF-ratified cousin, TLS. SSL/TLS can offer four security services:
1) server authentication
2) channel encryption
3) channel tamper detection
4) client authentication
Usually you'll get server auth for free, but only if the host name and the common name in the server's SSL/TLS certificate match. If they don't match your browser will warn you. You usually get the channel defenses for free too, but that's only because the server and client negotiate to require such defenses. In theory, but rarely in practice, a server and client could agree to not use one or more of the channel defenses.
Finally, client authentication is when the server wants you to present a certificate (actually, to prove you have an associated private key) to verify you are you. Client authentication is rarely used.
Related
I have been reading about ssl/tls and certificates recently to enable https for one of our websites.
As far as my current understanding goes, a ssl/tls certificate verifies that we as client are connected to the correct site or not. For that the signature inside of the certificate is used to verify whether the certificate is legitimate or not. And finally to establish a secure connection algorithms like ECDHE (Elliptic curve Diffie–Hellman) are used.
My question is if I want to connect to a website say, "www.mysite.com" and I key in "www.mysite.com" into my browser address bar, I am guaranteed that I will be connected to the correct website. So what is the purpose of having a SSL/TLS certificate installed on a web server when I know that I am keying in the proper address.
Am I missing something in my understanding of how https works?
Also ECDHE algorithm does not rely on any information like public key from the certificate to establish a secure connection.
... if I want to connect to a website say, "www.mysite.com" and I key in "www.mysite.com" into my browser address bar, I am guaranteed that I will be connected to the correct website.
You are not. With a variety of techniques like DNS spoofing, ARP spoofing, hijacked SoHo routers, ... it is possible that an attacker reroutes your traffic so that it ends up at a server controlled by the attacker and not the actual server you want to. Validating that the certificate you've got from the server is the expected one protects against such attacks.
I could find any quick answer on google. Most probably the answer lies somewhere in RFC docs on http or https however I just couldn't (too time consuming ) get those information.
So here is the question:
Is the content of a webpage served through HTTP signed digitally by the server ? Same question for HTTPS.
If yes, how does it work correctly when using a proxy ? In my opinion the proxy could tamper the data, sign the tampered data with it's own private key, and claim that the corresponding proxy's public key is actually the genuine public key of the original server ? I am assuming that the client can't check the original server's public key, because there is a proxy which could lie.
I am sorry if this is a dump question and easy searchable on the internet, but every answer I found posed some doubts to me.
Thanks for your help :)
Content sent via HTTPS is encrypted, clients verify the authenticity of the host certificates with whom they are communicating. The server uses a TLS/SSL key/certificate which is signed by certificate authorities (CA) The CAs make sure that they only sign the certificates of the rightful owners of a domain. The certificates of the CAs them-self are installed in you browser/OS. By using these pre-installed certificates, the browser can check if the key used by the remote server is signed by a trusted CA.
A man-in-the-middle does not have the original key, nor another key signed by a CA for the domain in question. Therefore, a man-in-the-middle cannot modify the content without breaking HTTPS.
On the other hand, if you want to use a proxy to cache requests, the proxy can terminate the HTTPS connections. This means the proxy has its own connection to the server and verifies the certificates. In order to secure the connection to the client, the proxy acts as a CA and uses a HTTPS connection with self-signed certificates. To avoid that your browser complains about an insecure connection, you need to install the proxies own CA certificate.
HTTP content is not signed and can be tampered with.
Edit 2018-06-15:
I wasn't really precise with the term "signed" here. The server does not actually sign the content it sends. This means if you store the responses from the server, you cannot prove that they came from that server, in other words: standard TLS dose not provide non-repudiation. However, the authenticity of the server is established during the handshake. The client encrypts a master-key with the servers public key. Only servers in possession of the private key can decrypt the master-key and derive session keys from them.
CAs, on the other hand, actually sign the certificates. A CA cannot validly deny that it signed for the authenticity of a server certificate.
Over ssl/tls can a query string be logged as the request hops around the net before it gets to its endpoint.
I know the endpoint can log the query string. I also know the endpoint server is trusted so I don't mind any logging there.
The way points of TCP traffic will see HTTPS data as cipher text that can't be decoded.
Logging at a TCP way point would require a MITM (man-in-the-middle) attack, which would require the user to be tricked into accepting a forged certificate (which is why browsers are becoming more strict about limiting click-through).
There are proxies that do SSL inspection (a.k.a SSL intercept), which are effectively doing just such a MITM--but such proxies generate the forged certificates with a CA certificate (Certificate Authority certificate) that is installed as a trusted CA certificate on the organization's clients (often by way of GPO policies).
So if you are in such an organization, you're requests are almost certainly logged (with more detail than just your query string [a.k.a path]), and you're content is being subjected to either malware protection (usually downstream) and/or DLP (Data Loss Prevention, usually to keep you're organization's sensitive information from being leaked).
In school we got one teacher who always asks question which look easy but they are not easy.
So, can anybody please tell me in a very accurate way whats the difference between http and https authentication?
HTTPS is HTTP inside a SSL/TLS tunnel.
Like a postcard (HTTP) in an envelop (SSL/TLS).
SSL/TLS has 3 main properties :
authentication of the server : a trusted authority has signed the certificate used by the server
confidentiality : only the client and the server can decrypt the data
integrity : the data cannot be modified during the transport without the receiver notice it.
Note: SSL/TLS can be used with a certificate not signed by a trusted authority (but the client will show a warning about that)
HTTP does not scramble the data to be transmitted. That's why there is a higher chance that transmitted information is available to hackers. It operates at TCP/IP level. It uses port 80 by default.
HTTPS is a short abbreviation of Hyper Text Transfer Protocol Secure. It is highly advanced and secure version of HTTP. It uses the port no. 443 for Data Communication. It allows the secure transactions by encrypting the entire communication with SSL. It is a combination of SSL/TLS protocol and HTTP. It provides encrypted and secure identification of a network server.
Limitations of HTTPS---
HTTPS protocol can't stop stealing confidential information from the pages cached on the browser.
SSL data can be encrypted only during transmission on the network. So it can't clear the text in the browser memory.
Fot HTTP the browser performs basic handshake with the server as per the rules of HTTP protocol. It does not validate the authenticity of the server. However for HTTPS the browser validates the authenticity of the server using the SSL certificate with the client. If the certificate is authentic then ssl keys are exchanged between browser and server and all messages are encrypted thus preventing a man in the middle attack. In http there is no ssl certificate and all data is sent in plain text which is vulnerable to man in the middle attack
There is something I don't understand, When I don't put certificate at all, the SSL connection is established successfully, I wonder how the server decrypt the message without client certificate.
What is client side certificate is for?
Thanks
As I understand it (the 15000 metre view.)
The server has a public key it publishes in its cert. This is used by your browser to encrypt everything it sends. Only the server can decrypt the info as only it (hopefully) has the private key.
If you have a client cert then you give this to the server to ensure that it encrypts stuff to you so only you can decrypt it (again with your private key).
So to me: You can send your credit card info completely freely, knowing that only the server can read it. The client can either then send a proper cert or create a 'temp' one for the session and then the 'public' encryption key to the server secure in the knowledge that no one else will have sent it. Then the comms are encrypted both ways, but separately.
Now from here
A TLS client and server negotiate a
stateful connection by using a
handshaking procedure. During this
handshake, the client and server agree
on various parameters used to
establish the connection's security.
The handshake begins when a client
connects to a TLS-enabled server
requesting a secure connection, and
presents a list of supported
CipherSuites (ciphers and hash
functions).
From this list, the server
picks the strongest cipher and hash
function that it also supports and
notifies the client of the decision.
The server sends back its
identification in the form of a
digital certificate. The certificate
usually contains the server name, the
trusted certificate authority (CA),
and the server's public encryption
key.
The client may contact the server
that issued the certificate (the
trusted CA as above) and confirm that
the certificate is authentic before
proceeding.
In order to generate the
session keys used for the secure
connection, the client encrypts a
random number (RN) with the server's
public key (PbK), and sends the result
to the server. Only the server should
be able to decrypt it (with its
private key (PvK)): this is the one
fact that makes the keys hidden from
third parties, since only the server
and the client have access to this
data. The client knows PbK and RN, and
the server knows PvK and (after
decryption of the client's message)
RN. A third party may only know RN if
PvK has been compromised. From the
random number, both parties generate
key material for encryption and
decryption.
This concludes the
handshake and begins the secured
connection, which is encrypted and
decrypted with the key material until
the connection closes.
This wikipedia article probably gives more info than you'll ever want.
Think about certificate not in terms of encrypting-decrypting, but in terms of authentication. Encryption can be done without certificates at all - just knowing open key is enough. But certificate contains different fields, among them is personality of certificate owner. For web this value is the domain name of the server you wish to connect to. As there are means to check that IP address of the server is always equal to name stated in certificate (forward and backward DNS requests), you can be sure that you're talking to the one you wish to.
In this terms, client certificate issue should be much simpler to understand. Client certificate allows server to authenticate client, so the authentication will be mutual. Server could check, for example, that the client certificate is valid (not expired, not black-listed, etc.).
Using a certificate from either the server or the client will give the endpoints a means of exchanging a shared secret (a symmetric encryption key - or seed).
A secondary purpose for the certificate (and one that's much less well-leveraged these days, relative to "encrypting the channel between endpoints") is to authenticate the endpoint supplying their digital certificate (using the cert and the proof of possession that they also send).
The overwhelming majority of SSL transactions these days are effectively only worried about the "encryption of the channel", not to authenticate the endpoint. (Practically speaking, it's a side benefit on the commercial internet, though the mass of man-in-the-middle attacks out there give us increasing incentive to try to figure out how to really know you're talking to the server - or client - that you think you are.)
In other words, the client certificate would be useful to authenticate (in a more or less "stronger" manner) that the server is interacting with either (a) a "more trusted" client (if all you were doing was ensuring that the cert is among a pool of certs you trust - e.g. mapped to an LDAP/AD directory of users you deem "trusted", or issued from a CA whose issuing practices you "trust") or (b) a specific user that you authenticate (e.g. again, through an LDAP/AD database of user, one - or more uncommonly, or more - of which has been mapped to that certificate through some automated or out-of-band - but either way, hopefully a sufficiently secure - process).