Hope this is not something obvious, just want to clarify some things I am not totally sure about. I got this question while watching a tutorial on how to implement caching. There is seems that just adding some global caching variables on the server, will implement caching for all clients. I use PHP with Apache webserver.
I know that a web-server can accept multiple client HTTP requests. My question is what happens on the web server code.
Is the same server code executed each time? Meaning that some global variables are preserved? Or for each new HTTP request, a new instance of the code is created. If yes, are those multiple instances connected or can be made aware of each other in any way?
Bad news is the apache server does not native support for that kind of work. You have to use some intermediate stuff like database to handle this.
However, good news is node.js do that stuff easily in an elegance way :D
Related
This was a question in a recent interview I took. I answered, that to my awareness there is no such way. But I am not sure.
Is there a way to stop Apache web server from answering an HTTP request?
I used PHP as the language of choice, if it makes a difference.
To better understand this answer you need to understand the networking "OSI 7 Layer Networking Model". (More details here: https://en.wikipedia.org/wiki/OSI_model )
What this demonstrates is that Apache will "handle" a request before PHP code even begins to execute. (Apache operates at layers 5,6, and 7, where PHP Typically Operates on top of apache).
Therefore PHP code is going to be ill equipped to "stop" apache from Answering an HTTP request. Instead, you will want to look at blocking access entirely (A Firewall [Either hardware of software based], operating at layer 3/4) or you will need apache to have logic to not handle the request.
This is actually more of a security question, than a programming question. Typically for this use case you would want an apache module to make a determination inside apache about handling a request. A few good modules for this are: mod_evasive, mod_security
Mod_Evasive:
https://www.digitalocean.com/community/tutorials/how-to-protect-against-dos-and-ddos-with-mod_evasive-for-apache-on-centos-7
Mod_Security
https://geekflare.com/apache-web-server-hardening-security/#6-Mod-Security
Please let me know if you have any questions, Thanks!
Currently I try to improve the performance of my Play! application and i'm thinking about how to handle multiple instances (Scaleability) in future. The application should run with SSL.
Now I read: https://www.playframework.com/documentation/2.4.x/HTTPServer
It states:
Note that using a front end HTTP server will rarely give you better performance than using Play server directly. However, HTTP servers are very good at handling HTTPS, conditional GET requests and static assets, and many services assume a front end HTTP server is part of your architecture.
Does that mean that it would be a good idea to run the Play! app just as HTTP server (not HTTPS) and put a lighthttpd in front, configured for SSL, which acts as a proxy for the Play! app?
In very general yes, you can use frontend HTTP server for several purposes and minimize stress on your application, there's no reason to handle i.e. requests to static and public assets, as probably HTTP server will do it faster and/or better, that way your app will handle only traffic which is required to be handled by app.
Further, you can also use FE server as a load balancer and divide stress put on single app - to several instances even on separate machines.
TL;DR
I want to set up a local HTTPS proxy that can (LOCALLY) modify the content of HTML pages on my machine. Is this possible?
Motivation
I have used an HTTP Proxy called GlimmerBlocker for years. It started in 2008 as a proxy-based approach to blocking ads (as opposed to browser extensions or other OS X-specific hacks like InputManagers). But besides blocking ads, it also allows the user to inject their own CSS or JavaScript into the page. Development has seriously slowed, but it remains incredibly useful.
The only problem is that it doesn’t do HTTPS (from its FAQ):
Ads on https pages are not blocked
When Safari fetches an https page using a proxy, it doesn't really use the http protocol, but makes a tunneled tcp connection so Safari receives the encrypted bytes. The advantage is that any intermediate proxies can't modify or read the contents of the page, nor the URL. The disadvantage is, that GlimmerBlocker can't modify the content. Even if GlimmerBlocker tried to work as a middleman and decoded/encoded the content, it would have no means of telling Safari to trust it, nor to tell Safari if the websites certificate is valid, so Safari would think you have visited a dubious website.
Fortunately, most ad-providers are not going to switch to https as serving pages using https are much slower and would have a huge processing overhead on the ad-providers servers.
Back in 2008, maybe that last part was true…but not any more.
To be clear, I think the increasing use of SSL is a good thing. I just want to get back the control I had over the content after it arrives on my end.
Points of Confusion
While searching for a solution, I’ve become confused by some apparently contradictory points.
(Also, although I’m quite experienced with the languages of web pages, I’ve always had a difficult time grokking networks and protocols. On that note, sorry if I’m missing something that is way obvious!)
I found this StackOverflow question asking whether HTTPS proxies were possible. The best answer says that “TLS/SSL (The S in HTTPS) guarantees that there are no eavesdroppers between you and the server you are contacting, i.e. no proxies.” (The same answer then described a hack to pull it off, but I don’t understand the instructions. It was very theoretical, anyway.)
In OS X under Network Preferences ▶︎ Advanced… ▶︎ Proxies, there is clearly a setting for an HTTPS proxy. This seems to contradict the previous statement that TLS/SSL’s guarantee against eavesdropping implies the impossibility of proxies.
Other things of note
I can’t remember where, but I read that it is possible to set up an HTTPS proxy, but that it makes HTTPS pointless (by breaking the secure communication in the process). I don’t want this! Encryption is good. I don’t want to filter anyone else’s traffic; I just want something to customize the content after I’ve already received it.
GlimmerBlocker has a nice GUI interface, but I’m fine with non-GUI solutions, too. I may have a poor understanding of networking and protocols, but I’m perfectly comfortable on the command line, tweaking settings in text editors, and so on.
Is what I’m asking possible? Or is my question a case of “either you get security, or you can break it with hacks and get to customize your content—but not both”?
The common idea of a HTTP proxy is a server which accepts a CONNECT request which includes the target hostname and port and then just builds a tunnel to the target server. All the https is done inside the tunnel, so there is no way for the proxy to modify it (end-to-end security from browser to web server).
To modify the data you need to have a proxy which plays man-in-the-middle. In this case you have a https connection between the proxy and the web server and another https connection between the browser and the proxy. Between proxy and web server the original server certificate is used, while between browser and proxy a newly created certificate is used, which is signed by a CA specific to the proxy. Of course this CA must be imported as trusted into he browser, otherwise it would complain all the time about possible attacks.
Of course - all the verification of the original server certificate has to be done in the proxy now, and not all solutions do this the correct way. See also http://www.secureworks.com/cyber-threat-intelligence/threats/transitive-trust/
There are several proxy solution which might do this SSL interception, like squid, mitmproxy (python) or App::HTTP_Proxy_IMP (perl). The last two are specifically designed to let you modify the content with your own code, so these might be good places to start.
I need answer to one very basic question.
Is it necessary to have telnet access to hit an API while systems are connected over VPN? For example, if my system exposed an API for other systems to hit and they are connected in VPN using IPsec, does a third party system needs telnet access to my server for using that API? The API uses soap protocol for receiving request and sending response.
(I did not find out the solution using google. The question is so naive that I had to assume everyone must already know the answer and does not bother to discuss it in web. Sorry for bothering with this simple question)
This is very strange. Accessing an http endpoint for anything else than dev using telnet doesn't really make much sense to me. If someone is using telnet to fetch informations from a server in an application. Something is already really wrong. If telnet is timing out while doing http requests. It's not really your fault and you shouldn't have to worry about edge cases like this.
If the dev is using telnet to discover security issues. This is a different issue and you could probably log anything that come from this particular client. If you gave hime some credentials, it should be easy to find who is doing which request. (I believe you might be already doing this).
You should probably ask the dev "why are you using telnet?". If for whatever reason the dev though he could send a plain SOAP request to your server using telnet without sending HTTP headers and so on.... then yes the connection is likely to timeout because the server isn't going to handle the request.
In my twisted mind, I can imagine some kind of legacy application calling scripts that open telnet sessions to parse some data and return the "parsed" data to the patched legacy project that doesn't handle http/tcp. I'd have in mind some sort of old Cobol application. Much more easier to do system call than to rewrite the whole thing to support APIs.
If for whatever reason, the client claims that telnet is needed for whatever reason. You can tell him back that telnet shouldn't be considered secure. Your api can be accessed using https. As far as I remember telnet doesn't encrypt anything unless you send encrypted data. If your client was able to hack a solution using telnet, I'm pretty sure they can hack a different solution wich use an actual http client.
I am very new to both node and Javascript, and am completely lost when it comes to PHP and Apache/nginx. I have an Amazon EC2 instance running my node server, which I am accessing through my browser via http://[my-ip]:[port-number]/.
There are a couple of things I'd like to accomplish -- most importantly, I'd like to require a username/password before the server will accept a client. A secondary objective, but one that I feel may be required in order to password protect the server, is to do away with the port number specification through some kind of proxy forwarding.
I've seen that others have accomplished this by adjusting server configurations and/or other utilities such as haproxy, but the examples were a little over my head and I'd like to understand what I'm doing at each step, because for me this project is more about learning than anything else.
Again, I am VERY inexperienced, so an easy-to-follow, bottom-up suggestion for how I should go about doing this would be very much appreciated!
So let's split your question into two:
a) Password protect server
I'm guessing you are talking about the basic HTTP auth. If you are using Express, you can use the Connect middleware in order to achieve that.
Find the example here: https://github.com/senchalabs/connect/blob/master/lib/middleware/basicAuth.js
Read more about it here: http://senchalabs.github.com/connect/middleware-basicAuth.html
b) You want a proxy. In production I'd say to choose HAProxy like you were suggested, but there are also other alternatives written in Node.js like bouncy or node-http-proxy which you can find more easy to understand.