In some countries like Iran or china because of severe Internet censorship, people use a foreign VPN server to bypass government censorship.
Imagine we implement a none-SSL VPN for people who connect their phone to the Internet through this VPN. I want to know if they use a secure application within their phone which is secured by SSL like Instagram or WhatsApp, still, is there any security issue for the transmitted data between their phone and server?
I mean is it possible in this case their data would be sniffed by the government or others? (although the VPN is none-SSL but Instagram is SSL secured)
If I understand the scenario you have described, the VPN does not use SSL when communicating with the user device, but the secure application requires the use of SSL between the server and the client device.
The answer would depend on a few more things. Does the "severe internet censorship" flat out restrict the usage of the application? Take Instagram for example. Is the government banning the use of the application in its entirety or just certain aspects (such as filtering specific tags)? Sometimes the term "internet censorship" is used to mean one of these things but not the other (though most often the former).
Assuming the application is banned in its entirety, and the connection to the VPN is not secured by SSL, then the domain which is being banned would be visible to eavesdroppers at some point prior to the secure channel establishment (with SSL or rather TLS) between the client device and server. For example, it is likely the case that the DNS resolution of the domain is unencrypted (either at the client device level or communicating the query to the VPN). So, the eavesdropper (say, the government) would be able to see this and possibly act on it (say by dropping the request if they have a middlebox unknown to you).
So basically, if the connection to the VPN is not secured by SSL (or TLS) then there would be no benefit in using the VPN with regards to censorship.
Related
I was thinking about how to secure my API and prevent token theft from affecting my users. I thought it would be a good idea to save my users IP if an attacker manages to steal a token and is used by one with a different IP. I'm going to use a middleware or a function to verify if it is in the user ip list and if not I'm going to reject his token and then ask for your credentials in the frontend. If the credentials are correct I will overwrite the IP or store it as a new one.
I don't know exactly what you mean by "is it feasible". Yes, you can do it if you want.
But, there are plenty of potential issues with relying on a user's IP address not changing and forcing them to reauthenticate every time it does change.
1. Mobile devices moving around. As mobile devices move on a cellular network, their IP address can legitimately change.
2. Mobile devices connecting to different networks (such as WiFi). As your phone goes from being in your car and on the cellular network to being at home and on your WiFi network, that phone's IP address in connecting to your service will change.
3. NAT behind some firewall. Nearly every user (even home users) are going through a NAT device and the IP address you're seeing is the IP address of a gateway, not the actual user's IP address. In a larger corporate network, the gateway IP address may not always be the same. And, multiple different users may appear to be from the same gateway IP address so there is not necessarily a one-to-one correspondence between users and IP addresses.
In general, you should just be using https for all connections in which you transmit the JWT so there is little risk of man-in-the-middle attacks stealing the JWT. The user themselves needs to secure their own local storage of the JWT.
An approach used by many modern services is to fingerprint the local device by recording a set of characteristics it has which may even include the presence of some other cookie along with a number of other browser characteristics. Then, you require reauthentication whenever the fingerprint changes by some significant amount. You will see many bank and airline websites doing something like this. The idea here is that even if the credential is stolen, then the fingerprint is unlikely to match when a credential is being used by an attacker.
I am developing a Node.js app based on the Express framework. On the backend, I need to have servers talk to each other (ie. Server 1 make a request of Server 2).
Is it OK to forego a DNS A-Record and just use the IP address of the server?
In that case, how do I authenticate the server and "client" (aka server). I was thinking of requiring the server and "client" to each pass a secure cookie with their request and responses. The secure cookie would then be verified before any other action was taken.
Using a IP might be more secure then DNS (e.g. no DNS spoofing), but it still allows ARP spoofing, e.g. some other computer claims to have this IP. And in case both computers are not in the same network there are also ways to hijack requests in routers etc.
The secure cookie is nothing else as a shared secret. And contrary to public key based authentication (e.g. using certificates) shared secrets have the disadvantage that you need to distribute them in a secure way so that nobody else gets access to them.
I don't think that your idea is easier to handle than SSL with certificates, so I don't see an advantage of making your own secure protocols. History tells us, that such homegrown protocols mostly provide worse security than established solutions.
If you don't care about security (these hosts are on your network, in which you have trust), don't bother with the homebaked cookies.
If you do care about security get (or generate your own) certificate and use SSL.
I was thinking of requiring the server and "client" to each pass a secure cookie with their request and responses. The secure cookie would then be verified before any other action was taken.
This is not secure at all! Anybody situated on an appropriate network between the client and server can see that "secure cookie", as well as any subsequent communications. This would allow them to reuse that cookie themselves to impersonate either the client or server, and would expose any sensitive information sent in the exchange.
Use SSL. It has already solved all of these problems, and more.
Given a bunch of machines who are on the network and who shall talk to each other using TCP.
My demands are:
Data must be encrypted.
Data must not be sent to an unauthorized machine even if it is on the same network.
Data must not be received from an unauthorized machine.
Machines know only the IP addresses of the other machines.
For a better imagination, think of a chat network where only authorized clients are allowed to participate, and all communication shall be encrypted.
My initial idea was to use a TLS certificate:
Each authorized machine has a copy of that certificate.
Using the certificate the connection can be encrypted.
Using the certificate on the server side it can be used to verify the server.
Using the certificate on the client side it can be used to authenticate a client.
As unauthorized machines do not have the certificate, they can neither decrypt, send nor receive data.
In theory, this should work out as expected.
In practices, it doesn't.
One of the problems is that the machines only know each other's IP address, and that they need not be bound to a domain name. As certificates are not recommended for IP addresses (and Node.js won't even validate a certificate with an IP address as CN), and the IP addresses may even change over time, I started to think whether that's the correct approach.
Of course, I could start implementing all this by myself: An encryption layer, an authentication schema, ... but I don't run after that. If there's a more convenient way of solving this, I'd appreciate this.
So, basically it comes down to use an TLS certificate for encryption and authentication, not because of the binding to a domain name, but because a specific certificate is present.
How would I implement this and solve the above mentioned issues?
Or - am I running in a completely wrong direction? How might I solve this in a better way?
As part of strengthening session authentication security for a site that I am building, I am trying to compile a list of the best ways to register a user's computer as a second tier of validation - that is in addition to the standard username/password login, of course. Typical ways of registering a user's computer are by setting a cookie and or IP address validation. As prevalent as mobile computing is, IP mapping is less and less a reliable identifier. Security settings and internet security & system optimization software can make it difficult to keep a cookie in place for very long.
Are there any other methods that can be used for establishing a more reliable computer registration that doesn't require the user to add exceptions to the various cookie deleting software?
If you're looking to do device authentication, you may want to consider mutually authenticated SSL. Here, you'd deploy a client identity certificate to each endpoint you'd want to authenticate. Then, you set the server up to require client authentication, so that a client would need to present a valid identity certificate in order to form the SSL tunnel.
This, of course, is not a perfect solution. In reality, this presents much of the same weaknesses as other solutions (to various degrees) Once your client identity certificates go to your clients, they are out of your control; should a client give their certificate to anyone else, you lost the device authentication that you have based on it. SSL identity certificates are generally stored in a keystore on the client which is encrypted with a password or other credential needed to unlock them. While a client certificate could still be compromised, it's somewhat stronger that just a cookie or something like that (assuming you don't have a client that is trying to give away its credential). In addition, you'd want to come up with some validation routine that a client would need to go though in order to get a credential in the first place (how do I know that this is a client device that I want to remember/register?).
Remember, these types of approaches only do device authentication, not users. There are more in-depth schemes already developed for device authentication than what I've mentioned; for example, 802.1x is a network protocol where an endpoint needs to present a client-side certificate to the network switch to get on a LAN. This is out-of-scope for a web application scenario, like what you've described, but the idea is the same (put a cryptographic credential on the client and validate it to establish the connection).
This, like all other security matters really, is a risk decision. What are you trying to accomplish with such a countermeasure? What are the threats you're trying to prevent and what are the consequences if someone does log in on an unregistered device? Only your situation can answer those questions and let you see the real risk, if you need/should mitigate it, and, if so, how strong of a solution do you need to get the risk level down to an acceptable level?
the best ways to register a user's computer as a second tier of
validation
From my point of view this approach does not offer much in the aspect of authentication.
You are not authenticating a user and have no idea who is using the PC that you would accept as being registered.
The way you describe it, this step should be a configuration rule in the firewall to accept connections from specific IPs only.
IMO the filtering of the PCs is the responsibility of a firewall and it would be much better handled by the firewall than any application level filtering.
Just think that you would have the overhead in your application to examine each request and decide whether to accept it or not.
Better leave this preprocessing overhead to the firewall. That's why it is there.
I'm reading a book on WCF and author debates about pros of using message-level security over using transport-level security. Anyways, I can't find any logic in author's arguments
One limitation of transport
security is that it relies on every
“step” and participant in the network
path having consistently configured
security. In other words, if a message
must travel through an intermediary
before reaching its destination, there
is no way to ensure that transport
security has been enabled for the step
after the intermediary (unless that
interme- diary is fully controlled by
the original service provider). If
that security is not faithfully
reproduced, the data may be
compromised downstream.
Message security focuses on ensuring the integrity and privacy of
individ- ual messages, without regard
for the network. Through mechanisms
such as encryption and signing via
public and private keys, the message
will be protected even if sent over an
unprotected transport (such as plain
HTTP).
a)
If that security is not faithfully
reproduced, the data may be
compromised downstream.
True, but assuming two systems communicating use SSL and thus certificates, then the data they exchange can't be decrypted by intermediary, but instead it can only be altered, which the receiver will notice and thus reject the packet?!
b) Anyways, as far as I understand the above quote, it is implying that if two systems establish a SSL connection, and if intermediary system S has SSL enabled and if S is also owned by a hacker, then S ( aka hacker ) won't be able to intercept SSL traffic travelling through it? But if S doesn't have SSL enabled, then hacker will be able to intercept SSL traffic? That doesn't make sense!
c)
Message security focuses on ensuring the integrity and privacy of individ-
ual messages, without regard for the network. Through mechanisms such
as encryption and signing via public and private keys, the message will be
protected even if sent over an unprotected transport (such as plain HTTP).
This doesn't make sense, since transport-level security also can use encryption and certificates, so why would using private/public keys at message-level be more secure than using them at transport-level? Namelly, if intermediary is able to intercept SSL traffic, why wouldn't it also be able to intercept messages secured via message-level private/public keys?
thank you
Consider the case of SSL interception.
Generally, if you have an SSL encrypted connection to a server, you can trust that you "really are* connected to that server, and that the server's owners have identified themselves unambiguously to a mutually trusted third party, like Verisign, Entrust, or Thawte (by presenting credentials identifying their name, address, contact information, ability to do business, etc., and receiving a certificate countersigned by the third party's signature). Using SSL, this certificate is an assurance to the end user that traffic between the user's browser (client) and the server's SSL endpoint (which may not be the server itself, but some switch, router, or load-balancer where the SSL certificate is installed) is secure. Anyone intercepting that traffic gets gobbledygook and if they tamper with it in any way, then the traffic is rejected by the server.
But SSL interception is becoming common in many companies. With SSL interception, you "ask" for an HTTPS connection to (for example) www.google.com, the company's switch/router/proxy hands you a valid certificate naming www.google.com as the endpoint (so your browser doesn't complain about a name mismatch), but instead of being countersigned by a mutually trusted third party, it is countersigned by their own certificate authority (operating somewhere in the company), which also happens to be trusted by your browser (since it's in your trusted root CA list which the company has control over).
The company's proxy then establishes a separate SSL-encrypted connection to your target site (in this example, www.google.com), but the proxy/switch/router in the middle is now capable of logging all of your traffic.
You still see a lock icon in your browser, since the traffic is encrypted up to your company's inner SSL endpoint using their own certificate, and the traffic is re-encrypted from that endpoint to your final destination using the destination's SSL certificate, but the man in the middle (the proxy/router/switch) can now log, redirect, or even tamper with all of your traffic.
Message-level encryption would guarantee that the message remains encrypted, even during these intermediate "hops" where the traffic itself is decrypted.
Load-balancing is another good example, because the SSL certificate is generally installed on the load balancer, which represents the SSL endpoint. The load balancer is then responsible for deciding which physical machine to send the now-decrypted traffic to for processing. Your messages may go through several "hops" like this before it finally reaches the service endpoint that can understand and process the message.
I think I see what he's getting at. Say like this:
Web client ---> Presentation web server ---> web service call to database
In this case you're depending on the middle server encrypting the data again before it gets to the database. If the message was encrypted instead, only the back end would know how to read it, so the middle doesn't matter.