An internal team, separate from my own, has stated that they prefer to do incoming authentication based on client certificates. Which sounds good to me, except that I haven't messed with them before and aren't quite sure where to start researching (Wikipedia went straight into a lot of detail that I'm not sure is pertinent to what I need to find out). If I have an IIS6 server with a web app that runs under an AD user account, what steps should I take to eventually fire off a request from that web app to a remote server, via .NET (I'm guessing HttpWebRequest)? I do see that we have an internal trusted certificate authority and all. Remote server is running Apache on Linux boxes.
I'm essentially in learning mode, not necessarily looking for a blow-by-blow list of what needs to happen (though if I could learn how it works while learning how to do it, that'd be nice too :) ... do you have any resources I could start looking into in order to figure out how to successfully authenticate securely via SSL with this remote server and communicate with it via client certs? Probably from creation of the client cert on up, though I'd like to more fully understand how it all works in the first place.
Here is a link - http://support.microsoft.com/kb/315588. Hope this helps with what you are looking for.
Related
Friendly Disclaimer: I am new to working with Keycloak and IdP in general. So it's likely that I use incorrect terminology and/or am more confused than I think I am. Corrections are gratefully accepted.
My question is conceptual.
I have a TLS certificate that is terminated on my host machine by my host company. My reverse proxy (Traefik) is picking up that certificate.
Which of the following proxy modes should I use now to be able to deploy Keycloak to production: edge, reencrypt or passthrough? (see here for relevant documentation)
I can pretty much rule out passthrough, because as I wrote, the TLS certificate is terminated on the server. But I am unsure if I have to bring my own certificate and reencrypt or if it is considered safe to go along with edge?
I have done my best to keep this question short and general. However, I am happy to share configurations or further details if needed.
As far as I know, most organizations consider a request to be safe when the proxy validated and terminated the TLS. It also removes the performance overhead (depends on your load). Unless your organization is going for Zero Trust for its internal network, using the edge should be totally acceptable.
We're having an authentication problem with our self-made collaboration website.
We have server A with the Collab platform. We log on with our domain account on the website. This website talks to an API on Server B but Server B should also be able to get data from out intranet (Sharepoint) on server C. Is this the double hop issue? NTLM is uses, not Kerberos.
Do we need to change everything to Kerberos? I found a lot about double hop but none have a decent explanation on how to configure/fix it.
Server A & B are 2012R2, server C is 2016.
Yes. When you need authenticate a user on a web server and then re-use and pass credentials from the web server to another server, that is the "double-hop" scenario. The only way to allow this, is to establish a Kerberos trust between those two machines. This is done in Active Directory.
You don't need to "convert all of your stuff to Kerberos" because it is already built-into any server that is on an Active Directory domain.
In IIS, you will need to set the "IIS", "Authentication" to use "Digest" authentication (of course Anonymous is disabled).
There are dozens of great articles that walk you through anything that I didn't mention. (Like this one) It is not difficult, but it takes some time to learn it the first time. So there is no need to worry.
I've created WCF Service and I share it via ssl. I have little knowledge about security, but I'm curious why can I see whole communication as a plain text in httpAnalyzer, even though POSTs are sending via https?
When my client application invokes wcf service, then I can see it in sniffer - passwords etc.
Does it mean that SSL works only on the lower layer - while transporting data? So every evil application can sniff communication on client's side and an encryption only secures us against man-in-the-middle?
SSL works indeed on a "lower layer" than HTTP. According to the OSI Model, SSL works on the Session Layer, while HTTP is on the Application Layer.
Most of these clientside HTTP Analyzers work from within the browser, analyzing the HTTP traffic on the application layer, before it is processed by the SSL logic. So it is completely normal to see the plain HTTP request.
Concerning security, an evil application installed within the browser can indeed read upon the traffic. But once it is processed by the SSL layer, it becomes way harder for an evil application to read the traffic.
SSL works by firstly authenticating the server to you as a client. (Do I talk to the one I really want to talk to). As you can't know all of the servers and their certificates before hand, you use some well known root certificates, which are pre-installed on your OS. These are used to check if some server is perhaps known by an already well known service. (I don't know you, but some really important server tells me that you indeed are who you say you are).
This authentication step works independent from the encryption of the traffic. No program can decrypt an arbitrary SSL stream by "installing a root certificate". (As said these root certificates are already on your machine from the first moment you install an OS on it =)
But if a evil programs is able to let you believe that you are talking to a legitimate server, using a forged root certificate for example, instead of actually talking to malware, it is able to see what the contents of the SSL traffic is. But then again, you are talking to the evil program itself, not the server you were intended to talk to. This is however not the case with HTTP Analyzer
This is in short terms how SSL works and hopefully answers your question.
Most likely HTTP analyzer install it's own root certificate, and intercepts SSL traffic, working as man-in-the-middle.
I am faced with a WCF security scenario that isn't particularly well documented online.
I am developing a product licensing service in WCF that will be deployed along with our software (i.e. the service is running on the same PC as the client). This licensing service will be responsible for a number of things related to controlling use of our software and connecting to our remote licensing server for updates, revocations etc. Consequently it's not the kind of service I want spoofed, and I don't really want spoof clients communicating with it either.
As it's running on the same PC as the client can anyone suggest a security policy for this scenario? I'm particularly interested in authentication as most of the other security principles are straightforward. I'm reluctant to get into certificates if I can help it but as mutual authentication is a priority I'm beginning to think I may need to implement a custom 'challenge/verify' scheme between the service and client.
Any ideas? Thanks for reading.
Chris.
My suggestion is that no matter how much effort you put into that, there will be an attack vector that makes all of your effort null and void. One option is to use ILMerge to provide a single dll for your entire application, and store it encrypted on disk and create a loader that hits your service passing in the registration information. On your side, the service will validate the customer information and send back a decryption key. The loader would use the decryption key to decrypt the DLL in memory and load it dynamically.
The shortcoming of this approach is that a determined cracker could debug your application and when the DLL is decrypted, write the unencrypted stream to disk. Your only means of retribution would be to place some kind of marker on the DLL so that you can identify who was responsible for breaking your copy protection and bring legal action if it's found open on the Internet.
As long as you're deploying this software to the client, then you cannot store any kind of key inside it without risking compromise. Even if you use certificates, you cannot hide them from the client while still making them visible to your application. And if you embed the key in the assembly itself then someone will just pop it open using Reflector.
Assuming you don't care about outright cracking (i.e. patching the assembly's code to simply bypass the license checks), then there's one and only one correct way to implement this type of security and that is to mimic the way a PKI works, by using a remote server exclusively.
In a PKI, when a server needs to validate a client via a certificate, it checks that certificate against the certificate authority's CRL. If the CRL reports that the certificate is revoked then it refuses access. If the CRL cannot be contacted then the certificate is considered invalid.
If you want to implement this scenario then you need 3 logical services but not in your current configuration. What you need is a remote licensing server, a client, and an application server. The application server can, theoretically, reside on the client, but the key aspect of this app server is that it performs license checks against the remote licensing service and handles all of the important application logic. That way, "spoofing" the server becomes an almost impossible task because a casual cracker would have to reverse-engineer the entire application in the process.
This is significantly less safe than making the application server a remote server, and may not offer many advantages over simply embedding remote security checks in the client itself and scrapping the local app/licensing server completely. But if you are determined to take this 3-tier approach then the aforementioned architecture would be the way to go.
Again, this is assuming that you aren't worried about "direct" cracking. If you are, then you'll have to read up on techniques specific to that particular attack vector, and understand that none of them are foolproof; they can only slow an attacker down, never stop him completely.
On a customer's internal network, I can make a request to my SSL site using IE6 SP1 (on Win2K) and see one cert validation requests, but if I use IE6 SP2 (on XP) 13 separate cert validation requests get fired off. Needless to say, this slows down my page load a lot.
Firefox loads the page just fine with no unnecessary cert validation requests.
The server is Apache running a pretty new lampp stack. All the server certificate / CA chain configurations seem to be fine (users can authenticate w/ trusted certs, the system can communicate to other systems with that server cert, etc.)
Is there anything I can do from a configuration standpoint? Any other ideas at all?
I'm guessing that "upgrade IE" is off the table, right? You're probably trying to find a way to support IE 6.0, SP2, with XP, so your users can use this version.
OK... one thought is trying to mess with the SSL configuration. As I remember, SSL has a number of settings that can be used and perhaps you can change one of them on your server and get a different behavior. It might be worth it to research what's happening during the SSL Handshake on the working and not-working versions of IE 6.0. I favor Ethereal, a free network traffic watching tool that will capture the SSL. It can't decrypt it easily, but you can at least see the first few messages that happen in the clear. It might give an inkling into why all these validation requests are coming in.