If I authenticate my clients using SSL client certs, is that necessarily a site-wide filter, or can I either require or not require authentication per-URL from within an application? So I'd like
https://mysite.com/my_url doesn't care who the client is, just uses 'normal' https
https://mysite.com/my_sensitive_url requires that the client is using a valid client cert
I'm working in Ruby on Rails, but I'm interested in the general question of whether SSL client cert authentication is flexible enough for this. I can imagine that a hand-written apache conf with different settings for different URLs could probably do it, but I'd really much rather define this kind of thing at the application level.
You would (a) set the server to do authentication via SSL certificates; (b) set the server to to 'want' rather than 'need' SSL client authentication, and then (c) define access rules for the specific URLs or patterns that required the user to be logged in, and not for the others.
Related
I use CloudFlare Access as a reverse proxy for my server, to protect it against denial of service attack and other benefits. I would like to protect access with mTLS which can be configured with CloudFlare. However, the verification options there are quite limited. I can filter for common name, ask for a valid certificate.
One thing I could do is use CloudFlare Worker alone to built a custom proxy, however I lose other benefits like the authentication from CloudFlare to my server using CloudFlare-signed JWT cookies.
How can I write a custom certificate validator without loss of any other functionality?
I did create a ssl virtualhost in apache with a self-signed certificate.
In my opinion the configuration is correct however it is possible to access this url using "curl --insecure".
Searching at google, reading several tutorials and trying several configurations (diretives SSLVerifyClient|SSLVerifyDepth|AuthType|AuthBasicProvider|AuthUserFile|Require valid-user) I did not have any success in block this url using "curl --insecure"
I have been thinking in testing mod_security but I don't know if is the right way.
Could you give me some advice?
Thanks
Hudson
I suspect you may need to refine the understanding of sleep. You can't force clients to verify your SSL certificate. Besides, if you're using a self signed cert, it would never verify for anyone who didn't add the cert to their ca library.
You could block curl by rejecting requests based on their User Agent string. But that's just a header, and can be set by the client to anything ( such as a "valid" browser URL). If you really want to control clients, one way would be to use client certificates, which is the analog of the server certificate you set up, but on the client side. In that case, in addition to the client (ostensibly) verifying the server's cert, the server would verify the client's cert, providing a very strong and reliable mechanism to verify client access. Unfortunately, due the the difficulty of generating keys and cert signing requests, and signing certs for clients, client http certificates are not common. But they're very secure, and a good choice if you control both sides.
A middle ground would be to add an authentication layer into your app to control who can access it (you'd then refuse unauthenticated requests altogether)
In short, though, none of these things block curl. They block clients who cannot authenticate. I would recommend you not focus on the remote browser/client in use ( that's at the discretion of your http client). instead, focus on providing the security authentication you require. IMHO, trying to block client user-agents is a fool's errand. It's security by obscurity. Anyone can set any user-agent.
I'm implementing an SSL layer for a web server project. I'm using polarSSL, though I think this question is a general SSL question.
When I get a connection to my server from a client I configure the SSL protcol like this:
ssl_set_endpoint( &mSsl, SSL_IS_SERVER );
ssl_set_authmode( &mSsl, SSL_VERIFY_NONE );
E.g. I'm not verifying the connection from the client. Do I need to do this?
Most browsers don't have client side certificates - though some do (I think). Is there any need or advantage for the server to verify the client? This is for a service where I would happily serve the data to a client that had no client side certificate at all.
Client-side authentication in SSL/TLS is used when it's required for the server to know its client. For example, it's widely used in banking, to access custom corporate servers etc.
In opposite, the common web server is intended to serve wide audience and not care about who's coming in. So client-side authentication is not used unless you know that you need it.
Does anybody has a WebLogic 8.1 two-way SSL full example?
I am developing a small web application (1 HTML, 1 Servlet, 1 JSP) to send confidential data. The client could be a web browser. The server is WebLogic 8.1.
The information should travel encrypted. Besides, the web application needs to authenticate the client, using more than a username/password combination. I thought implementing using HTTPS and two-way SSL authentication. This way, the user should send me her certificate, I installed in the server, so the web application could know when it is sending information.
Now, I know how to use declarative authorization in a web application, but I am lost on how specify which users I recognize, and which are their certificates.
I just need a full example of this. A .war and/or the steps to do the basic case.
I don't think you'll find a full example easily and the question is a bit broad. But the link your provided is a very good starting point.
First configure Two-Way SSL and use CLIENT-CERT. Clients will need to buy a trusted client certificate or to generate a self-signed certificate that you'll need to add to the server trust store. This may be the hardest part if you're not familiar with PKI but I've added resources at the end of this answer that cover this part. Load the client certificate in each client browsers.
Second, configure an Identity Assertion provider to map the digital certificate of a Web browser to a user in a WebLogic Server security realm. If required, provide your own user name mapper or use the default one (which uses the attributes from the subject DN of the digital certificate or the distinguished name to map to the appropriate user in the WebLogic Server security realm).
Third, add users corresponding to the Subject's Distinguished Name (SubjectDN) attribute in the client's digital certificate in Weblogic Security Realm and assign them to groups.
Finally, use these groups in your declarative authorizations.
Sure, it won't be that easy if everything is new but that's basically what you need to do. Maybe start to implement it and open more specific questions if you need more guidance.
More resources:
Two-Way SSL in Weblogic for Developers
The Fifteen Minute Guide to Mutual Authentication
Certificate to User Mapping in WebLogic
How to Set Up X509 Certificate Authentication for Oracle WebLogic Server (transposable to WLS 8.1)
I setup my own open id provider on my personal server, and added a redirect to https in my apache config file. When not using a secure connection (when I disable the redirect) I can log in fine, but with the redirect I can't log in with this error message:
The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
I'm guessing that this is because I am using a self signed certificate.
Can anyone confirm if the self signed certificate is the issue? If not does anyone have any ideas what the problem is?
The primary benefit of using SSL for your OpenID URL is that it gives the relying party a mechanism to discover if DNS has been tampered with. It's impossible for the relying party to tell if an OpenID URL with a self-signed certificate has been compromised.
There are other benefits you get from using SSL on your provider's endpoint URL (easier to establish associations, no eavesdropping on the extension data) which would still hold if you used a self-signed cert, but I would consider those to be secondary.
OpenID is designed in a redirect-transparent way. As long as the necessary key/value pairs are preserved at each redirect, either by GET or POST, everything will operate correctly.
The easiest solution to achieve compatibility with consumers that do not work with self-signed certificates is to use a non-encrypted end-point which redirects checkid_immediate and checkid_setup messages to an encrypted one.
Doing this in your server code is easier than with web server redirects as the former can more easily deal with POST requests, while also keeping code together. Furthermore, you can use the same end-point to handle all OpenID operations, regardless whether or not it should be served over SSL, as long as proper checks are done.
For example, in PHP, the redirect can be as simple as:
// Redirect OpenID authentication requests to https:// of same URL
// Assuming valid OpenID operation over GET
if (!isset($_SERVER['HTTPS']) &&
($_GET['openid_mode'] == 'checkid_immediate' ||
$_GET['openid_mode'] == 'checkid_setup'))
http_redirect("https://{$_SERVER['HTTP_HOST']}{$_SERVER['REQUEST_URI']}");
As the openid.return_to value was generated against a plain HTTP end-point, as far as the consumer is concerned, it is only dealing with a non-encrypted server. Assuming proper OpenID 2.0 operation with sessions and nonces, whatever information passed between the consumer and your sever should not reveal exploitable information. Operations between your browser and the OpenID server, which are exploitable (password snooping or session cookie hijacking) are done over an encrypted channel.
Aside from keeping out eavesdroppers, having authentication operations be carried out over SSL allows you to use the secure HTTP cookie flag. This adds yet another layer of protection for checkid_immediate operations, should you wish to allow it.
(Disclaimer: I'm new to OpenID, so I might be wrong here.) The communication between the Open ID Consumer (e.g., StackOverflow) and the Open ID Provider (your server) does not require HTTPS -- it will work just as fine and just as securely over plain HTTP. What you need to do is to configure your server to switch to HTTPS only when it shows you your login page. In that case, only your browser needs to concern itself with the self-signed certificate. You could import the certificate onto your PC and everything will be as secure as with, say, Verisign-issued certificate.
It sounds like it. The client of your OpenID server doesn't trust the root certification authority.