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.
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 understand that HTTTPS is secured and it requires SSL certificate issued by CA authority to make the application secure. But what I do not understand is that its in-depth difference with HTTP.
My question, as a user, if I make a request to an application with HTTP or if I make same request to HTTPS what is the actual difference? The traffic remains same to both. Is there any traffic filtering happening if I use HTTPS?
Thanks
HTTPS, as an application protocol is just HTTP over TLS, so there are very few differences, the s in the URL and some consequences for proxy, that is all.
Now you are speaking about the traffic and the filtering. Here you have a big difference because using TLS adds confidentiality and integrity: passive listeners will see nothing about the HTTP data exchanged, including headers. The only thing visible will be the hostname (taken from the https:// URL) as this is needed at the TLS level before HTTP even happens, through a mechanism called SNI (Server Name Indication) that is now used everywhere to be able to install multiple services using TLS under different names but with a single IP address.
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
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?
I am quite new to HTTPS and can not get my head around it.
Can someone suggest good starting point for learning about HTTPS, certificates and signing?
Possibly with a working example in ASP.NET with IIS.
If all you are trying to do is have your site in HTTPS there is no code needed. All you need to do is set IIS to serve pages with HTTPS.
If that is all you want, you are better off asking this question in http://www.serverfault.com.
To get you started, here's a link on how to set https in iis 7: http://learn.iis.net/page.aspx/144/how-to-setup-ssl-on-iis-70/
HTTPS is just normal HTTP traffic that is encrypted using SSL/TLS. The protocol is fairly straightforward. I wrote a detailed blow-by-blow of what happens at the start of a connection on my blog: The First First Few Milliseconds of an HTTPS Connection.
It's unfortunate that the APIs built on top of the protocol are often much more complicated.