we need to protect our webservices with SSL (https) or any other security mechanism. Our problem is that current clients (delphi exe's) have references to our http webservices fixed in code and can not change that code.
I've tried to implement URL redirection rule from http to https but that didn't work because of the "hand shake"...Changing client to use https reference did work but saddly we can not do that for every client.
I know this question is in contradiction with encription theories but i'll fire this question anyway if anyone has any type of suggestion/idea to at least make connection or data transfer more secured (either with or without SSL protocol) without changing client side.
Thanks,
Luke
You need some kind of transparent TCP tunneling software/hardware on the clients, so the encryption occurs without the delphi clients noticing it.
My Google search using "transparent encrypted tunneling" keywords got this vendor of such solutions. There's must other vendors with similar solutions.
This is really an networking question.
PS.: hardcoding the URL is the real problem here. After the tunneling palliative is done, change that because this really will cause more headaches in future.
The client will be connecting over a port (non SSL) that will need to remain. What you could possibly do is that if you allow access both http and https you could possibly only allow http from specific IP addresses if you know them? its still not secure, but least you know where the calls are coming from and can do something about that?
Related
Is there a way to detect if someone has charles proxy or a network tracking app, tracking your program's requests/apis. And if so is there a way to prevent such a thing.
Just wanted a bit of insight into this, any information is much appreciated.
It's possible to achieve it: Here are two solutions I could think of
After the SSL finish, you can get the certificate and check whether or not it's a self-signed certificate. Then, you might reject the Request connection.
Use the SSL-Pinning technique that only accepts the certificate from your own and rejects others. It will prevent the app is intercepted from Charles Proxy or other Proxy tools like Proxyman, Fiddler, and Wireshark.
I've some discussion with my colleague whether we can make HTTPS connection without using SSL certificate. I'm quite confused about this. Can anyone explain this?
It's not possible to do HTTPS connections without SSL. The way it works is complicated and as mentioned in the comments there is a great answer here.
But to summarize the reason why it's not possible:
HTTPS needs an SSL certificate, you can think of SSL as the S in HTTPS, since the secure connection is made using the certificate. A client sends a request to a server, they do a secure handshake (which requires the certificate in order to create and verify the keys) and then proceed to business as usual.
Any browser will throw a million red flaws if you try to circumvent this behavior. You could trick your own server to believe data is coming as HTTPS rather than HTTP in some cases (if you have control over it), but you won't be able to fool browsers.
I'm implementing an HTTP proxy. Sometimes when a browser makes a request via my proxy, I get an error such as ECONNRESET, Address not found, and the like. These indicate errors below the HTTP level. I'm not talking about bugs in my program -- but how other servers behave when I send them an HTTP request.
Some servers might simply not exist, others close the socket, and still others not answer at all.
What is the best way to report these errors to the caller? Is there a standard method that, if I use it, browsers will convert my HTTP message to an appropriate error message? (i.e. they get a reply from the proxy that tells them ECONNRESET, and they act as though they received the ECONNRESET themselves).
If not, how should it be handled?
Motivations
I really want my proxy to be totally transparent and for the browser or other client to work exactly as if it wasn't connected to it, so I want to replicate the organic behavior of errors such as ECONNRESET instead of sending an HTTP message with an error code, which would be totally different behavior.
I kind of thought that was the intention when writing an HTTP proxy.
There are several things to keep in mind.
Firstly, if the client is configured to use the proxy (which actually I'd recommend) then fundamentally it will behave differently than if it were directly connecting out over the Internet. This is mostly invisible to the user, but affects things like:
FTP URLs
some caching differences
authentication to the proxy if required
reporting of connection errors etc <= your question.
In the case of reporting errors, a browser will show a connectivity error if it can't connect to the proxy, or open a tunnel via the proxy, but for upstream errors, the proxy will be providing a page (depending on the error, e.g. if a response has already been sent the proxy can't do much but close the connection). This page won't look anything like your browser page would.
If the browser is NOT configured to use a proxy, then you would need to divert or intercept the connection to the proxy. This can cause problems if you decide you want to authenticate your users against the proxy (to identify them / implement user-specific rules etc).
Secondly HTTPS can be a real pain in the neck. This problem is growing as more and more sites move to HTTPS only. There are several issues:
browsers configured to use a proxy, for HTTPS URLS will firstly open a tunnel via the proxy using the CONNECT method. If your proxy wants to prevent this then any information it provides in the block response is ignored by the browser, and instead you get the generic browser connectivity error page.
if you want to provide any other benefits one normally wishes from a proxy (e.g. caching / scanning etc) you need to implement a MitM (Man-in-the-middle) and spoof server SSL certificates etc. In fact you need to do this if you just want to send back a block-page to deny things.
There is a way a browser can act a bit more like it was directly connected via a proxy, and that's using SOCKS. SOCKS has a way to return an error code if there's an upstream connection error. It's not the actual socket error code however.
These are all reasons why we wrote the WinGate Internet Client, which is a LSP-based product for our product WinGate. Client applications then learn the actual upstream error codes etc.
It's not a favoured approach nowadays though, as it requires installation of software on the client computer.
I wouldn't provide them too much info. Report what you need through internal logs in case you have to solve the problem. Return a 400, 403 or 418. Why? Perhaps the're just hacking.
I am managing a web application that dynamically flips between http and https depending on the page. I want to get rid a ton of extra code used to flip between http and https but I want to understand any implications before I continue.
Is there any advantage to serving part of a site using http over https?
Of course there is some performance drop when using https, but it is not significant unless you have an extremely busy server. See
HTTP vs HTTPS performance
HTTP is not a secure protocol and anyone can intercept the transmitted data in cleartext (e.g. session cookies, passwords, credit card numbers, sexual fetishes). If you can, you should provide consistent HTTPS service throughout.
That said, by the design of the public/private key security, you can only use HTTPS on a server where you have complete and sole control over the IP address, since the client first looks up the IP address, then requests the secure protocol, and only then makes the HTTP query. That means that you cannot deploy HTTPS on virtual hosts (shared hosting).
(Since you already have a partial HTTPS solution, I imagine that's not a problem for you, though.)
The other downside is that the secure handshake and later encryption require computing resources, so that if you have bazillions of connections, you may feel quite a hit on your server performance. That's for you to consider, though.
Short form: If you have a dedicated IP address and enough computing resources, always and exclusively use HTTPS.
Using http is faster than https obviously since you do not have the ssl handshake overhead during connection establishment or the extra encryption/decryption delay.
If you only need parts of your web site to be secure e.g. just encrypt the login credentials, then it makes sense to have the code for the redirection so that the interaction after that is faster due to plain-text http.
If there are many areas of your site that need to be secure, then you could make measurements using https completely and see if the performance is significantly affected.
If you see no significant performance issues (or the performance is acceptable), then you could simplify your software design and remove the redirection logic between http<->https and use https everywhere.
One of the differences between HTTP and HTTPS is that with HTTPS, you loose the ability to have intermediaries (caches, proxies, etc) between the client and server do anything useful with requests and responses because the content is encrypted. From a security point of view, this is a good thing because it prevents intermediaries from snooping or tampering with traffic. On the other hand, you reduce the opportunities for dealing with things like scalability, performance and evolvability.
In general on any non-HTTP server. Would there be a way to detect what domain was used to reach the IP?
I know HTTP servers get the domain passed within the request header, but would this be possible with any other server that does not require this information to be received from the client?
I'm especially looking for a way to do this with the minecraft server (Bukkit) so my preferred language (if needed for you to answer) would be Java. But I'd like to not have the theories about this language specific.
In general, no, which is why the HTTP protocol includes it in the headers.
In order to reach your server, first a DNS lookup is performed to resolve your IP, which is then followed by the connection itself. These two steps are separate, and hard to link together.
Logging what domain was last requested by a client is tricky, too, as DNS information is often cached, so the DNS request may not even reach your DNS server before being answered.
If it isn't cached, it also often isn't directly looked up by the end client, but rather by a caching DNS server operated, for instance, by the ISP.
No. The only way to get the DNS name used to connect to a server is to have the client provide it.
No, if there are no means for this in the protocol itself like the Host header in HTTP you cannot find out which hostname was used on the client to resolve your IP address.