when we use https.........for example to send login credentials(https://example.com?username=aaaa&password=aaaa123). HTTPS encrypts the data using SSL certificate. So the url will be encrypted string. I am giving two requests with the same url(https://example.com?username=aaaa&password=aaaa123). On every request the url will be encrypted. Will the encrypted url of the first request be same as the encrypted url of the second request? Is the SSL certificate going to be different everytime btween client and server?
Thanks,
Iqbal
Will the encrypted url of the first request be same as the encrypted url of the second request?
The URL will be the same, because you said so. If you're asking whether the encryption of the URL will be different, the question is meaningless. It's impossible for anyone to tell, because the entire request is encrypted, so it is impossible to pick out the part that consists of the encrypted URL.
Is the SSL certificate going to be different everytime btween client and server?
The SSL certificate is the same for the entire SSL session, which persists beyond the current connection for as long as both client and server remember it.
Related
https retrieves data from the server in secure way, http or https post method as I know sends data encoded for reassuring sensitive information. If both https and post method secures data what is the difference
HTTP POST request will be sent unencrypted and any middle man in the communication can see the plain text
However with HTTPS all the data is encrypted and only the server can decrypt it to see the data that's coming
You maybe misunderstanding that encoding is not encryption by the way.
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.
I am trying to understand how to bypass HSTS protection. I've read about tools by LeonardoNve ( https://github.com/LeonardoNve/sslstrip2 and https://github.com/LeonardoNve/dns2proxy ). But I quite don't get it.
If the client is requesting for the first time the server, it will work anytime, because sslstrip will simply strip the Strict-Transport-Security: header field. So we're back in the old case with the original sslstrip.
If not ... ? What happens ? The client know it should only interact with the server using HTTPS, so it will automatically try to connect to the server with HTTPS, no ? In that case, MitM is useless ... ><
Looking at the code, I kinda get that sslstrip2 will change the domain name of the ressources needed by the client, so the client will not have to use HSTS since these ressources are not on the same domain (is that true?). The client will send a DNS request that the dns2proxy tool will intercept and sends back the IP address for the real domain name.At the end, the client will just HTTP the ressources it should have done in a HTTPS manner.
Example : From the server response, the client will have to download mail.google.com. The attacker change that to gmail.google.com, so it's not the same (sub) domain. Then client will DNS request for this domain, the dns2proxy will answer with the real IP of mail.google.com. The client will then simply ask this ressource over HTTP.
What I don't get is before that... How the attacker can html-strip while the connection should be HTTPS from the client to server ... ?
A piece is missing ... :s
Thank you
Ok after watching the video, I get a better understanding of the scope of action possible by the dns2proxy tool.
From what I understood :
Most of the users will get on a HTTPS page either by clicking a link, or by redirection. If the user directly fetch the HTTPS version, the attack fails because we are unable to decrypt the traffic without the server certificate.
In the case of a redirection or link with sslstrip+ + dns2proxy enabled with us being in the middle of the connection .. mitm ! ==>
The user goes on google.com
the attacker intercept the traffic from the server to the client and change the link to sign in from "https://account.google.com" to "http://compte.google.com".
The user browser will make a DNS request to "compte.google.com".
the attacker intercept the request, make a real DNS request to the real name "account.google.com" and sends back the response "fake domain name + real IP" back to the user.
When the browser receives the DNS answer, it will search if this domain should be accessed by HTTPS. By checking a Preloaded HSTS list of domains, or by seeing the domain already visited that are in the cache or for the session, dunno. Since the domain is not real, the browser will simply make a HTTP connection the REAL address ip.
==> HTTP traffic at the end ;)
So the real limitations still is that the need for indirect HTTPS links for this to work. Sometime browser directly "re-type" the url entered to an HTTPS link.
Cheers !
What i want to do is to parse the method-type of a HTTPS message using wireshark.
I saw that for a HTTP message I see that for a 'GET' message, on the first row I see 'Get ...'.
Now I want to check the same for a HTTPS message, but I dont see any field flagging the method-type.
What am I missing?
HTTPS is HTTP inside a SSL tunnel. So you need to first decrypt the data of the SSL tunnel before you could find out which method is used. Unless you can get access to the keys of the encryption there is no way to decode the content and get at the HTTP traffic.
HTTPS is HTTP over SSL. The entire HTTP request is encrypted as SSL record and that is what the server receives. And server/client reach this stage only on setting up the SSL tunnel successfully. You need to invoke appropriate methods to unwrap the SSL layer and get the application data.
I assume you are trying to decode it from Wireshark. You will need to posses the server's private key to get the data out. Wireshark has the means to load the key. It shall then display the decrypted data in the capture. - http://support.citrix.com/article/CTX116557
To get around the problem of an SSL-terminating load balancer (it doesn't forward client certs to the application servers), our ISP has configured our environment such that client certificates are forwarded within the HTTP headers to the real servers (as X-Client-Cert).
I will be authenticating clients with a PIN mapped to the serial number of the certificate they've been issued with. But how do I get at the certificate from the custom header?
I assume you know that you can get the certificate data using
String s = Request.Headers["X-Client-Cert"];
The question is now in which format the certificate is added to the header. I would assume that it is encoded in Base64.
byte[] certdata = Convert.FromBase64String(s);
Then you can create the certificate object from it:
X509Certificate cert = new X509Certificate(certdata);
Depending on if the load balancer checks the client certificate for validity (and if it has been singed by the correct root CA) or not you have to check the validity of the certificate yourself or not.
Afterwards you can just read the serial number via cert.GetSerialNumber();