I am currently looking into OPENWRT and want to know where in OPENWRT receives the web http response e.g. in GZIP or Deflat format?
So the user connects to the WIFI through the router installed OPENWRT. The user sends a request for e.g. example.com. When the example.com sends the http response in whatever format to the user, it must first arrive at the router and can be intercepted by OpenWRT. I want to know where OpenWRT does this job so i can make some manipulations to the web response before it arrives at the user's device
OpenWRT doesn't actually "intercept" web responses from arbitrary urls. It's default state is as a more pure router, which means that it largely operates on "network" layer traffic and below. "Web response[s]" are considered "application" layer. See this diagram of the network layer stack:
What you can do is install a piece of software on the openwrt router which will inspect application layer information and make manipulations. You should know that this can significantly slow traffic on your router. Here's a list of available openWRT proxies:
http://wiki.openwrt.org/doc/howto/proxy.overview
Depending on what "manipulations" exactly you're trying to achieve, tinyproxy might work. Squid is a more full-featured option, but may slow down traffic too much and has the potential to crash routers without sufficient RAM.
http://wiki.openwrt.org/doc/howto/proxy.tinyproxy
https://www.google.com/search?q=openwrt+squid
Related
I know in airports, for example, I've connected to their AP, and it pops up a browser window to log in on my device. Is it possible to do so with NodeMCU in lua, or even with c firmware?
This can accomplished by setting the DNS server for a connecting client [via DHCP] to a sort of DNS proxy. It doesn't need to be a fully featured DNS server, it only needs to be able to either return a static DNS answer for any host name query or forward the request to a real DNS server, to resolve host names as usual.
The static answer effectively hijacks web requests at the DNS level, by forging the DNS answer, causing all host names to resolve to the IP address of a local web server. That local web server ignores any Uri details and serves a login prompt for every request. It must also maintain a list of client MAC addresses that have authenticated.
NodeMCU does have a built-in DHCP server, as part of it's built-in WiFi AP, but running both a web and a DNS proxy in ESP8266's limited memory would be a hell of a trick. I think that two of them working cooperatively, interfaced using the SPI bus might be workable... maybe even three of them, one dedicated to maintaining the list of authenticated MACs, expiring them, etc.
Note that the only part of this I have done on an ESP 8266 is some very simple web server functionality, so it's mostly theory. If you try it I'd be very interested in hearing about it. :-)
You might want to try out CaptiveIntraweb project (https://github.com/reischle/CaptiveIntraweb) which is based on NodeMCU.
There is also thread (http://www.esp8266.com/viewtopic.php?f=32&t=3618) on ESP8266 community forum that discusses the solution details.
I am accessing 2 URLs. The domain name/server part is the same. The resource part is different.
The URLs are like the following:
https://aa.bb.com/dir1/dir2
https://aa.bb.com/dir3
When I access the first URL, I get redirected to the second URL. Is it possible that the second URL be hosted on a different web server than the first or both resources would be on the same web server?
If by web server you mean physical computer, absolutely they could be on different servers. Google and Akamai, among others, have large collections of machines serving the same domain names. It helps with speed, since you are likely to receive pages from a server near you.
In general, it does not appear to be possible to reliably tell whether you are talking to the exact same server before and after a redirect. First, it is difficult to test for IP addresses from a Web page (see, e.g., this question and this one). Second, even if the IP addresses are the same before and after the redirect, they may be on different machines. For example, TCP anycast can change which server you are talking to without changing the IP address. Also, network address translation and load-balancing may change which server you are talking to behind a firewall, which you would probably have no way of finding out unless the server provided some ID of its own.
I'm trying to make a secure protocol between an iPhone app and an Arduino server. The goal is that the iPhone app makes a request to an Arduino server and the server only processes it if it has the proper credentials of one form or another. I'm not really sure how to approach this problem. Any suggestions are much appreciated!
Unfortunately there are no truly secure communication options available on Arduino. The basic problem is that SSL libraries have not been ported to this platform, partly owing to the fact that the 8-bit processors the platform is built around are not very powerful. Having said that there are some things you can do, but you'll have to do them yourself:
Basic access authentication is a very insecure method of controlling access to HTTP pages so it isn't recommended. Digest access authentication, on the other hand, employs one-way cryptographic encoding (hashing). It only requires MD5 library, which, is actually available for Arduino. What you'll need to do is modify the source code for the Web Server class to support digest access authentication: AFAIK it does not support it out of the box.
If this seems to difficult, you could implement something fairly basic (and not very secure, but better than nothing) yourself. It might look like this:
The first GET request comes in from a client
The server responds with "not authorized" response, embedding in the response a token which is related to (perhaps a hash of) the requesting IP address. You could make the original timeframe part of the hash as well, and give such tokens a limited lifetime.
If the next request from the same IP address includes a hash based on some secret code + the token sent, the next request is honored.
Now this will not protect you from IP address spoofing, and many other things I probably haven't thought of. However, it will give you a modicum of security (and a tiny bit of security through obscurity, if you believe in this sort of a thing). You could ask for (slightly) more elaborate schemes on superuser
You might be able to just use authenticated messages built on shared secrets. The message will contain [at minimum] a message type, message body, timestamp, and message digest. You create the digest by HMACing the other stuff with a shared secret. (Type HMAC Arduino into Google for libaries and code.) The message is sent over TCP or UDP (i prefer it). The Arduino computes digest of message, checks it, validates data, and then acts on message.
One thing I like to do is implement port-knocking or something at the network layer in front of the application server. This prevents unwanted traffic from reaching the custom (and possibly vulnerable) command server. This can be done stealthily (see Silent Knock) or obviously. The network protections can also be implemented by a dedicated device that does the heavily lifting and disqualifies much rogue traffic before it reaches the Arduino.
I'm writing a library that implements a distributed object system over a socket connection. I'm requiring that users sign any messages sent, at least when communicating over a network, as otherwise an attacker could pose as one of the participants and remotely call methods on the other, which would be a Bad Thing.
The main use of this library is for network communications. However I want to make it as simple as possible to get a 'hello world' example running locally without compromising someone's machine. Is it reasonable to assume that incoming data from a connection to localhost is really from localhost without securing it in some other way? Are there any other reasons that this might not be secure?
In case it's relevant, I'm working on OSX/iOS.
Connection on loopback is secure unless you have remote login enabled on the machine. Users can easily redirect connections with ssh(1).
Whether it is a good idea to complicate your code by not verifying messages from loopback is a different question that you have to ask yourself.
I'm working with the API using HTTMultiParty and I'm having trouble capturing the outgoing HTTP requests when I make POSTs. I don't see them at all in wireshark. I am capturing on the wireless adapter (I have no other internet connection) and filtering on
http.host contains "docusign"
but I can't see anything come up. Even with just an HTTP filter, I see nothing new captured while I see a request and response. Why is wireshark unable to view the traffic from my rails app? Note: I can see the request made by my browser to the rails app.
Since it's https traffic, assuming you know the IP address of the server you're talking to, use the filter ip.addr == x.x.x.x and you should see TLS traffic leaving leaving your client.
I presume in the above comments that you mean "ip.dst" because there is no such thing as "tcp.dest" as far as I'm aware.
Slightly old but here's a complete list of filters.