Am i correct that when using State Server traffic between my web site and the state server isn't encrypted? If it isn't, how can i secure it (SSL)?
The ASP.NET Session State server uses clear-text http-requests in a rest-like manner for communication. The actual protocol specification is publicly available at [MS-ASP]: ASP.NET State Server Protocol Specification.
I've never heard of anyone encrypting the state traffic, cant find any references for it, and nothing that states that it's even possible.
It's impossible for any of us to say whether the traffic between your web site and state server is encrypted or not.
At a high level, state server uses clear text for transferring the data. But this doesn't necessarily mean it's not encrypted.
However, depending on how your network is setup it might be encrypted at a lower layer by the operating system. Namely, if the machines are part of a domain the network administrator might have turned on the proper settings to force kerberos encryption between the machines.
Further, if you encrypt the data prior to putting it in "session" then it would obviously be encrypted.
If you are worried about internal threats then your network should be configured to encrypt all traffic between machines. (if you want to know how, go to serverfault.com).
The state server should be behind the firewall and not public, there should be no reason to encrypt the traffic. You would only want to make sure that the traffic is only able to go to and from the web tier to the state server via network layering.
Related
I'm going to be using gRPC for a device to device connection over a network (my device will be running Linux and collecting patient data from various monitors, gRPC will be used by a Windows client system to grab and display that data).
I obviously want to encrypt the data on the wire, but dealing with certificates is going to be a problem for various reasons. I can easily have the server not ask for the client cert, but so far I've been unable to find a way around the client validating the server's cert.
I've got several reasons I don't want to bother with a server cert:
The data collection device (the gRPC server) is going to be assigned an IP and name via DHCP in most cases. Which means that when that name changes (at install time, or when they move the device to a different part of the hospital), I have to automatically fixup the certs. Other than shipping a self-signed CA cert and key with the device, I don't know how to do that.
There are situations where we're going to want to point client to server via IP, not name. Given that gRPC can't do a cert for an IP (https://github.com/grpc/grpc/issues/2691), this becomes a configuration that we can't support without doing something to give a name to a thing we only have an IP for (hosts file on the Windows client?). Given the realities of operating in a hospital IT environment, NOT supporting use of IPs instead of names is NOT an option.
Is there some simple way to accommodate this situation? I'm far from an expert on any of this, so it's entirely possible I've missed something very basic.
Is there some simple way to set the name that the client uses to check the server to be different than the name it uses to connect to the server? That way I could just set a fixed name, use that all the time and be fine.
Is there some way to get a gRPC client to not check the server certificate? (I already have the server setup to ignore the client cert).
Is there some other way to get gRPC to encrypt the connection?
I could conceivably set things up to have the client open an ssh tunnel to the server and then run an insecure gRPC connection across that tunnel, but obviously adding another layer to opening the connection is a pain in the neck, and I'm not at all sure how comfortable the client team is going to be with that.
Thanks for raising this question! Please see my inline replies below:
I obviously want to encrypt the data on the wire, but dealing with
certificates is going to be a problem for various reasons. I can
easily have the server not ask for the client cert, but so far I've
been unable to find a way around the client validating the server's
cert.
There are actually two types of checks happening on the client side: certificate check and the hostname verification check. The former checks the server certificate, to make sure it is trusted by the client; the latter checks the target name with server's identity on the peer certificate. It seems you are suffering with the latter - just want to make sure because you will need to get both of these checks right on the client side, in order to establish a good connection.
The data collection device (the gRPC server) is going to be assigned
an IP and name via DHCP in most cases. Which means that when that name
changes (at install time, or when they move the device to a different
part of the hospital), I have to automatically fixup the certs. Other
than shipping a self-signed CA cert and key with the device, I don't
know how to do that.
There are situations where we're going to want to point client to
server via IP, not name. Given that gRPC can't do a cert for an IP
(https://github.com/grpc/grpc/issues/2691), this becomes a
configuration that we can't support without doing something to give a
name to a thing we only have an IP for (hosts file on the Windows
client?). Given the realities of operating in a hospital IT
environment, NOT supporting use of IPs instead of names is NOT an
option.
gRPC supports IP address(it is also mentioned in the last comment of the issue you brought up). You will have to put your IP address in the SAN field of server's certificate, instead of the CN field. It's true that it will be a problem if your IP will change dynamically - that's why we need DNS domain name, and set up the PKI infrastructure. If that's a bit heavy amount of work for your team, see below :)
Is there some simple way to accommodate this situation? I'm far from
an expert on any of this, so it's entirely possible I've missed
something very basic.
Is there some simple way to set the name that the client uses to check
the server to be different than the name it uses to connect to the
server? That way I could just set a fixed name, use that all the time
and be fine.
You can directly use IP address to connect, and override the target name in the channel args. Note that the overridden name should match the certificate sent from the server. Depending on which credential type you use, it could be slightly different. I suggest you read this question.
Is there some way to get a gRPC client to not check the server
certificate? (I already have the server setup to ignore the client
cert).
Is there some other way to get gRPC to encrypt the connection?
Note that: Even if you don't use any certificate on the wire, if you are sure the correct credential type(either SSL or TLS) is used, then the data on the wire is encrypted. Certificate helps you to make sure the endpoint to which you are connecting is verified. Failing to use certificates will leave your application to Man-In-The-Middle attacks. Hope this can help you better understand the goals and make the right judgement for your team.
I have a simple app connected to a server via some sockets and the traffic is not yet encrypted users must log in or create accounts before using the app and afterwards traffic is shared between users and server. i want to know if i must encrypt all traffic or just the authentication and account creation?
Use https for all traffic (or an equivalent TLS-based protocol for non-HTTP traffic). Yes, encrypt and certificate-authenticate everything. For modern systems, there are vanishingly few cases where TLS is not the correct answer for network traffic. It is ubiquitously available across platforms, languages, and protocols.
On any modern network system you need an argument for why you wouldn't encrypt and authenticate the connection. It's not a matter of "must" you. It's a matter of "why wouldn't you?"
I've heard from more than one IT Manager that they don't allow users to user RDP to connect to their internal network from the outside, because it's not safe. They claim that if they'd allow their users to do so, then anyone from the outside will have access to their network as well.
I'm not getting it. In order to use RDP, you need a user name and password, and you can't get in without it. The same is for using Gmail, online banking, and any other web service.
So what do they use instead? LogMeIn. Or a VPN connection, and then use internal RDP. VPN also requires a user name and password.
If they're afraid of a brute-force attack, then someone can brute-force attack the VPN server or LogMeIn just the same. And if these other technologies have lockouts (after x number of failed attempts) then why can't the same be set up for RDP?
Similarly, people always say that VPN is very secure because it uses a "tunnel". I don't fully understand what that means, but regardless, why can't the username and password be cracked the same way any website or web service which uses a user name and password can be.
With proper configuration, RDP is capable of 128-bit RC4 encryption, virtually any port or set of port allocations, and has proven to be relatively bug-free, with only extremely minor flaws ever discovered.
On the other hand, the secure tunnel created in a VPN is far more secure than Remote Desktop. All your data is encrypted for safe transfer from one remote location to another.
Moreover, VPN only allows shared content to be accessed remotely to tighten the security. If your device falls in the wrong hands, they won’t be able to access and manipulate unshared data and resources.
The bottom line is that both RDP and VPN have their own advantages, however, with high security, better performance and manageability, VPN seems to be a clear winner in the competition of Remote Desktop VS VPN service.
I'm working on an application that will be used from different locations so it has to be on a network, and since the distance from each workstation that will use the application is quite far, it will be on the internet. Definitely on a dedicated Windows Server.
I have security concerns because it is such an application that black-hat hackers and crackers will like to abuse to their own ends.
So I'm thinking, I can (since I am the I.T head of the company) procure a static IP address for all the workstations that will use the application, then I can compile a white list of IP addresses. If a request is not coming from an IP address in the white list, the request will be denied. Does this make sense?
I could also use more security tips on securing the server and the application.
It's an ASP.NET MVC application.
Does this make sense?
At a network level? Somewhat. At an application level? Probably not.
IP filtering is something that makes sense at the network level. So setting firewall rules to dictate which IPs are allowed to access certain ports on a server. That is both sensible and common.
Trying to do the same thing at the application layer is error prone and problematic. For instance, if your application is behind a load balancer, the IP address your application sees may well be the one belonging to the load balancer, not the client who originated the request.
As an additional note, just because a request is coming from a trusted IP, doesn't mean that you don't have to be careful. Your "trusted" client systems could be compromised or an attacker could be using a CSRF attack.
I have a web service with several web methods, each web method requires client machine to send their MAC Address and the server will validate this client base on this information (if not valid then return error) before proceeding to further operations. The communication between client and server is HTTPS. I only have about 20 clients or so. The question is is my way of doing this right/secure or not? If not then is there any simple way to do this?
Thanks,
It depends on your security requirements, there is no one definition of "secure enough". As others have said, the MAC can be spoofed, and is in effect just a shared secret/password. However, that is sufficient for many scenarios, when the confidentality of the connection is ensured by HTTPS. You need to define what threats you want to protect the system from, and how much you're willing to invest in security.
No, it's not secure because anyone who knows a valid MAC address in your database could call the web service. Of course knowing a valid MAC address in your database is unlikely possible, it's as if he knew a password.
The client can spoof the MAC address of the machines which is authorized. So, this is not secure.
Protecting your webservice through client certificates would provide better security.
Tutorial : http://www.codeproject.com/KB/WCF/9StepsWCF.aspx