I have a server/client architecture where the client hits the ASP.NET server's service at a certain host name, IP address, and port. Without thinking, I logged on to the server and set up permanent HTTP301 redirection through IIS from that service to another URL that the machine handles via IIS (same IP and port), mistakenly thinking it was another site that is hosted there. When the client hit the server at the old host name, it cached the permanent redirect. Now, even though I have removed the redirection, the client no longer uses the old address. How can I clear the client's cache so that it no longer stores the redirect?
I have read about how permanent HTTP301 can be, but in this case, it should be possible to reset a single client's knowledge of the incorrectly-learned host name. Any ideas?
The HTTP status code 301 is unambiguously defined in RFC 2616 as
any future references to this
resource SHOULD use one of the
returned URIs
which means you have to go ask all your clients to revalidate the resource. If you have a system where you can push updates to your clients, perhaps you can push an update to use the same URI again, but force a revalidation.
Nothing you do on the server side will help - in fact, by removing the permanent redirect in IIS you have already taken all measures you should.
Related
If a client is requesting a domain that does not have a valid CA signed certificate and the server not intend on supporting HTTPS but does support HTTP for this domain, what is the best way to handle this in the web server. Note, the server does handle requests for SSL (HTTPS) on other domains so it is listening on 443.
Example where this would apply is for multi sub-domains where the sub-domains are dynamically created and thus making it extremely difficult to register CA signed certificates.
I've seen people try to respond with HTTP error codes but these seem moot as the client (browser) will first verify the certificate and will present the hard warning to the user before processing any HTTP. Therefore the client will only see the error code if they "proceed" past the cert warning.
Is there a canonical way of handling this scenario?
There is no canonical way for this scenario. Clients don't automatically downgrade to HTTP if HTTPS is broken and it would be a very bad idea to change clients in this regard - all what an attacker would need to do to attack HTTPS would be to infer with the HTTPS traffic to make a client downgrade to unprotected HTTP traffic.
Thus, you need to make sure that the client either does not try to attempt to access URL's which do not work properly (i.e. don't publish such URL's) or to make sure that you have a working certificate for these subdomains, i.e. adapt the processes for creation of subdomains so that they not only have an IP address but also a valid certificate (maybe use wildcard certificates).
Considering these websites don't have to work with SSL, the webserver should close all SSL connections for them in a proper way.
There is no canonical way for this, but RFC 5246 implicitly suggests to interrupt the handshake on the server side by using the user_cancel + close_notify alerts. How to achieve this is another question, it will be a configuration of the default SSL virtual host.
user_canceled
This handshake is being canceled for some reason unrelated to a
protocol failure. If the user cancels an operation after the
handshake is complete, just closing the connection by sending a
close_notify is more appropriate. This alert should be followed
by a close_notify. This message is generally a warning.
If you are dealing with subdomains, you probably can use a wildcard certificate for all of your subdomains.
Adding the CA certificate to your client will remove the warning (that's what companies do, no worry).
When hosting with Apache, for example, you can use VirtualDocumentRoot to add domains without editing your configuration. Have a look at the solution provided here : Virtual Hosting in SSL with VirtualDocumentRoot
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 !
Scenario: I want a staging environment at a customer's site. The customer owns www.example.com. I want to map the site to staging.example.com reachable from the outside, but I haven't got time to wait for the bureaucracy surrounding either the purchase of the new subdomain or opening of secondary HTTP ports.
Assumption: If I spoof the HTTP Header param Host to be staging.example.com on the client side, but actually make the request to the IP of www.example.com, IIS will redirect the request to the configured site for staging.example.com. Am I right?
So is there any client tool that can help me with that? I'm fairly famailiar with Fiddler, but it seem to override my rewrites of the host parameter. Also I would need to configure it to do it for every request, not just one, to make it trivial to test.
Are there simpler solutions to this problem?
I'm not entirely sure what you're asking.
Inside Fiddler, by clicking Tools > HOSTS and you can send all traffic targeting one site, e.g. dev.example.com to the IP of your choice. The target site (namely dev.example.com) doesn't need to exist at all in this case. Your client (e.g. the browser) has no idea that Fiddler is retargeting the traffic, it just thinks that it is talking to dev.example.com.
If you have the Fiddler book, check out the Retargeting Traffic section for many other ways to retarget traffic.
I've got an internal web application that's designed to work in concert with a server running locally on the client machine. (For the curious: the local server is used to decrypt data retrieved from the server using the client machine's GPG key.)
The internal web app is served over HTTPS while the local app is accessible via localhost. It used to be that I could make unencrypted AJAX requests from the page to localhost without any issues; but it seems that recently Chrome was updated to disallow HTTP requests to any destination from pages served over HTTPS.
I understand that in the vast majority of cases, HTTP requests from a page served via HTTPS constitute a security hole. However, since I have complete control over the endpoint in this case (i.e., localhost), it seems to me that it should still be perfectly safe to make HTTP requests to that one destination even when the host page has been served via HTTPS.
Is this possible? To whitelist localhost somehow?
Since you are in control of both the client and the server, it sounds like a good candidate for Cross-Origin Resource Sharing (CORS). The server will have to set a few response headers to give access to the client. You can learn more here: http://www.html5rocks.com/en/tutorials/cors/
If I was to send a URL to a DNS server, lets say: "dev.example.com/?username=daniel",
what is exactly sent to the DNS server? The whole URL (including any passed parameters) or is it just website section "dev.example.com"? I want to know so that I know what parameters I should be hiding in a URL.
The reason I am asking is because I just don't want confidential information sent to DNS servers. I am using https for all URLs but when someone asks to go to a URL, I want all parameter information from the URLs to be hidden from all DNS servers. I just am not sure what is sent to a DNS server to establish an SSL connection. Since I have a site that needs just about every parameter encrypted I am concerned about how to hide this information if DNS reads it.
dev.example.com may be resolved (if it is not already in the local cache) by sending it to your DNS server (which will almost certainly refer to another DNS Server).
Only the "dev.example.com" is sent, the rest will be passed only to the resolved IP number as an HTTP request.
So, you do not need to hide any parameters, except of course that these parameters could well end up on another website if a user visits it from your page (as a referer). If these parameters are really sensitive encode them or (ab)use POST,
The Domain Name System (DNS) resolves hostnames to IP addresses, so only the value of the hostname is sent.
DNS is agnostic of protocol. The value sent is just the hostname, so in this case dev.example.com.
I'm also not sure what this has to do with "parameter hiding" but if you could expand on that we might be able to provide more helpful advice.
Edit (based on your update): Ah. Well then you shoud be good to go, as only the domain name itself is sent.
If the DNS server happens to be a web server which root web application happens to answer to the "username" query, then you might get something back. Other than that, DNS is another kind of animal.