What happens when a server without SSL makes an HTTPS request to a server that does? - security

In these instances, what happens? Does communication fall back to HTTP? I'm assuming that communication will either fail, or fallback, depending on the setup of the ssl-enabled destination server.
Example Case:
A plugin that is installed on Server A (which may or may not have SSL), communicates with an API that functions over HTTPS on Server B.

I think your question is not clear enough. Do you mean, with "a server without SSL", that
The server system has no kind of SSL software installed. In this case of course no SSL requests can be done from the server.
Or that the web server itself is only available by HTTP and not HTTPS, but there is a script on it which needs to access other hosts by HTTPS. In this case it can do these requests if the required software is installed on the server and if the target host is available by HTTPS and if no firewalls blocks the connections etc. Configuration of the web server itself has nothing to do what kind of requests programs on the web server can do.

Related

Can we make our own web server to host a websites and respond to HTTP requests?

A web server responds to an HTTP request and sends the client a set of HTML, CSS, and JS files.
After we build a website or a web application, we usually have to host it on a well-known web server like IIS or Apache to make it accessible all around the world (on the internet).
Can't we just make our own web server so that it can responds to all incoming HTTP requests that the client sends to our computer without having to use IIS?
As wazz and Lex says, you could build your own server to listen the special port and handle the request based on your requirement, but it contains performance and security issue.
If you still want to build it by yourself. I suggest you could refer to some existing server like KestrelHttpServer.

How to setup forward proxy on Windows server for outgoing HTTP and HTTPS requests?

I have a windows server 2012 VPS running a web app behind Cloudflare. The app needs to initiate outbound connections based on user actions (eg upload image from URL). The problem is that this 'leaks' my server's IP address and increases risk of DDOS attacks.
So I would like to prevent my server's IP from being discovered by setting up a forward proxy. So far my research has shown that this is no simple task, and would involve setting up another VPS to act as a proxy.
Does this extra forward proxy VPS have to be running windows ? Are their any paid services that could act as a forward proxy for my server (like cloudflare's reverse proxy system)?
Also, it seems that the suggested IIS forward proxy plugin, Application Request Routing, does not work for HTTPS.
Is there a solution for both types of outgoing (HTTPS + HTTP) requests?
I'm really lost here, so any help or suggestions would be appreciated.
You are correct in needing a "Forward Proxy". A good analogy for this is the proxy settings your browser has for outbound requests. In your case, the web application behaves like a desktop browser and can be configured to make the resource request through a proxy.
Often you can control this for individual requests at the application layer. An example of doing so with C#: C# Connecting Through Proxy
As far as the actual proxy server: No, it does not need to run Windows or IIS. Yes, you can use a proxy service. The vast majority of proxy services are targeted towards consumers and are used for personal privacy or to get around network restrictions. As such, I have no direct recommendations.
Cloudflare actually has recommendations regarding this: https://blog.cloudflare.com/ddos-prevention-protecting-the-origin/.
Features like "upload from URL" that allow the user to upload a photo from a given URL should be configured so that the server doing the download is not the website origin server.
This may be a more comfortable risk mitigator, as it wouldn't depend on a third party proxy service. A request for upload could be handled as a web service call to a dedicated "file downloader" server. Keep in mind that if you have a queued process for another server to do the work, and that server is hosted in the same infrastructure, both might be impacted by a DDoS, depending on the type of DDoS.
Your question implies that you may be comfortable using a non-windows server. Many softwares exist that can operate as a proxy(most web servers), but suffer from the same problem as ARR - lack of support for the HTTP "CONNECT" verb, which is used by modern browsers to start an HTTPS connection before issuing a "GET". SQUID is very popular, open source, and supports everything to connect to.. anything. It's not trivial to set up. Apache also has support for this in "mod_proxy_connect", but I have no experience in that and the online documentation isn't very robust. It's Apache, though, so it may be worth the extra investigation.

Submitting HTTPs from node socket with no certificate

A web application i developed is sitting on a server that serves it under https, some of my js code requires to open a socket to another server (nodejs) who is currently not set for https. and thus browser wont allow it to run.
all i want is a simple way without getting involved with certificates just to initiate a https socket connection, i don't mind the lack of security,
just need app to run.
The certificates are not your problem. Your problem is CORS. You need to configure your server to answer with a header allows foreign-origin
res.header('Access-Control-Allow-Origin', 'example.com');
because in your case the technical difference between http (port 80) and https (443) is the port.
EDIT: ... I mean from the browsers point of view

Integrate websockets with apache

I would like to add a some real time data updates using push to an existing CakePHP application. It seems to me that websockets are the best way to do so and from what I've read, the easiest way to start using websockets is with node.js. Now the issue I have is that my application server is very very limited portwise and there is virtually no way to change that.
I have apache currently running on *:80 and *:443 and sslh listening on port *:4433. Requests from the outside are sent to my server on :4433 and sslh takes care of handling ssh and https traffic, however on the inside, all my clients machines are using :443 directly. I could potentially open more ports for inside clients, but from outside, there is currently no way to do this. Most of my clients connect from the inside network, but more and more are using the application from outside too.
Note that port 80 is only used to redirect users entering http://example.com to https://example.com as all my services are encrypted. So if node.js was able to to send every http request to https and use port 80 for secure websockets, this would work too!
My question: Is it possible to run Apache and Websockets (probably in the form of Node.js) on the same port, and have either Node.js working as a proxy for Apache or Apache working as a proxy for Node.js?

SSL Https, is it that simple?

I'm just setting up an SSL area of a website, and was just wondering... is it as simple as adding HTTPS on the url?
(this is presuming I have a valid certificate of the hosting company?)
Or is there something more to it?
Thanks.
You have to setup the server to allow ssl connections. That includes generating a signed server request. You send this CSR to the cert authority (Verisign etc), and they send you a cert to install on the server. If you are behind a firewall you need to open port 443.
If you don't control the server i.e. shared hosting, there is probably a page in your control panel to do it all for you using a GUI.
When you replace http: in a URL with https: you are asking your web browser to do two things:
To attempt an encrypted (SSL) connection
To change which port to use on the remote server if none is specified in the URL
Most web browsers use port 80 for unencrypted traffic and port 443 for encrypted traffic by default. So, the first thing you need is a web server that is listening on port 443. If you are using a hosting company, this is probably already the case or becomes the case when you configure SSL.
You do not have to use port 443 but that is where browsers will be looking when users do not specify a port. You could also force everybody that connects at port 80 to use SSL as well though with the right configuration. That means that ALL traffic to your site would be encrypted.
To get the encryption up and running you generally need three things: a certificate, an encryption key, and a server request (CSR).
How you configure these is extremely dependent on how you are hosting the web server. Most hosting companies have 'control panels' that you log into for configuration. Common ones are Plex and CPanel. If either of those ring a bell you can post more information to get a better answer.
If you are managing the server yourself the big question is whether you are hosting on Windows or Linux. If it is windows, you are most likely going to want to configure IIS (Internet Information Server) while if it is on Linux you are probably going to configure Apache.
If you are using IIS, this link might help:
http://www.petri.co.il/configure_ssl_on_your_website_with_iis.htm
If it is Apache, Byron gave a good link above:
http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html
You can use other web servers. For example, I use nginx:
http://rubypond.com/blog/setting-up-nginx-ssl-and-virtual-hosts
So, I guess the real step one is finding out more about your server. :-)
Once your web server has the SSL cert installed, it is as easy as using HTTPS on the URLs. There are some considerations to be aware of:
Port 443 must be open between the user and web server. (obvious)
Browser caching will be reduced to in-memory session cache and not stored on disk. Also, caching proxies in between will not be able to cache anything, since everything is encrypted. This means an increase in load times and bandwidth requirements of the web server.
When using HTTPS to receive sensitive data, be sure to disallow its use over HTTP. e.g. If you have a page that accepts credit card numbers in a POST, the app should fail validation if it was not done over HTTPS. This can be done in your code or in web server configuration. This prevents a bug or malware from systematically sending sensitive data in the clear without the user knowing.

Resources