I am currently working on project that requires SSL Communication. What I want that login in page should prompt the user for their certificate (and it does, the first time). But when you click the 'Sign in' button on the Signed out page it's using the SSL state from the previous user and no certificate prompting occurs.
I do not want to clear SSL Cache after closing the browser or do it to manually in the browser.
I know that java script clears SSL Cache for the browser but it is not universal to all.
Is there any client or server side approach (for server side I only prefer java) to clear ssl cache.
Related
First of all i am sorry if this question is not valid, i am dealing with a situation where i have created the SSL certificate locally and its signed by local CA.
My frontend application is in angular and my backend application is in Spring boot when i try to connect to login from the UI then i need to add this certificate manually for that i had given a link button by clicking of that i will load the backend api in the browser
After this a popup will be open and the backend api will be loaded ,
then manually i need to click on the "Advance" and then proceed to unsafe . After all these steps certificate are getting added in the browser.
Can anyone suggest how to add this automatically without all these manual work.
You can use below configurations to enable self signed certificate on differernt browser. Although remember, this is not for PRODUCTION
Firefox : Go to URL https://localhost:<port_no> and add security exception to allow connections. If connection error still comes, Go to URL about:config and set value for security.mixed_content.block_active_content to false and security.mixed_content.block_display_content to true.
Chrome : Go to URL chrome://flags/#allow-insecure-localhost and click on Enable and restart Chrome to allow connections.
IE 10 and above : Go to URL https://localhost:<port_no> and add the certificate to Trusted Root Certification Authoritiesif certificate error comes.
You'll need to get a new Valid SSL Certificate. This might help
I have programmed a webserver meant to run on the user's localhost that gets jsonp requests from a remote https page. This architecture stems from the fact that applets are about to stop being supported by every browser and I need some sort of interface in between a smartcard and the browser.
I am planning to create a root certificate and the corresponding ssl certificate, and to start serving my jsonp endpoints using https.
In order to do so, I'd like my application to allow importing the root ssl certificate to the computer so that the browser does not complain when performing https requests to localhost.
(TL:DR) Is it possible to programatically install a root ssl certificate using java? Using which libraries?
I have just discovered that I shouldn't need to have any certificates installed. Taking in account the current w3c draft on my problem it seems that http://127.0.0.1* domains should not be considered mixed content in an otherwise safe webpage. Here is a link to the commit that added this to the draft, where one can read on its comment:
Based on the discussion in the public-webappsec thread starting at
3, our face-to-face at 4, and our recent call at 1, this patch
aligns mixed content's checks with Secure Context's definition of
potentially trustworthy URLs.
Among other things, this means that http://127.0.0.1/ will not be
considered mixed content when loaded in an otherwise secure page.
I have reported this issue for Chrome...
I have java web application which is running on several tomcats behind apache. Application use HTTPS protocol. Some pages from the app include images from sites which use only HTTP protocol. On pages with this images the client's web browser shows message (warning) that despite service is certified correctly some contents are not secure.
What should I do to avoid this message? Should I use some proxy for this images? Can I do something in java code?
Thanks in advance.
You can't do anything nor should you.
The browser is correct in warning the user even though there are no bad intentions here.
Using a proxy could be useful if you're really worried. In that case, the unencrypted connection is between your server and the hosts of the images instead of between the hosts and the user's browser.
Nothing you can do in java.
You need to register your certificate at some official certification authority, you can do that through the registration authorities.
A registration authority (RA) is an authority in a network that
verifies user requests for a digital certificate and tells the
certificate authority (CA) to issue it.
Google it. Of course you'll pay for that.
Also, you can avoid that browser message if manually add your certificate into Trusted Certificate on client machine.
I've spent the last day or so looking in CAS and have managed to get the server working with a simple test application. When I enter a protected area, I'm redirect to a login page - when I log in, I'm taken back to my previous page.
From there, the next step would be deploy two client applications, log into client A, visit the client B protected area and have the system handle the authentication for me (since I'm already logged into client A).
This isn't actually working however. I have to log into the client B site whether I'm logged into the client A site or not.
CAS is running on Tomcat, client A and B are the same project deployed as separate wars on a single instance of JBoss AS 6.
Any ideas how I can achieve the suggested behavior?
EDIT: Yes, both are using CAS. The issue is that it doesn't seem to be recognizing that the user is already logged in. It's as if the CAS isn't able to determine that there is a 'link' between the two services and that when one service has been authenticated, the other service should be automatically authenticated.
I should note that at this stage, I am not using SSL within the application. I'm focused on getting a simple example up and going using HTTP before I look at introducing SSL.
Both of your applications need to be configured to use the CAS server for authentication. The normal procedure would be that application A redirects you to your CAS login page, lets you log in and redirects you back to A. If you then try to log into B, it checks with the CAs server whether you're already logged in and, if so, sends back information about the logged in user.
Again, both your applications need to support CAS as a login mechanism, which I am not sure about from your description.
Detailed description of the CAS protocol can be found here.
CAS was working without SSL in that it would take you to the login site and authenticate you correctly. The issue was if you tried to access via another site, it would ask you to sign in again.
Once I enabled SSL and tried it, it was working correctly. Once logged into client A, it would automatically authenticate you in client B. I had spent some time on the wiki and while it spoke of the importance of using SSL, I do not recall it explicitly stating that SSO will not work without SSL enabled. Maybe a warning should be added to the wiki?
If you want to focus on your applications and make your life easier, use a cloud provider for the CAS server: http://www.casinthecloud.com (free servers are available for tests).
In case of webapplicaiton I can understand that there is no difference between the client authentication and user authenticaiton; Ignoring XSS and other exploits the web client is generated by the server/servlet.
But suppose you have a Java client application talking to the Java Server application; The server has a certificate associated with it so that the client can validate and verify if server is trusted. Now client also has a certificate (client cert) so that the server can verify if this is a trusted client; Once this mutual authentication is done, instead of presenting a username/password dialog to the user, the users certificate (user cert) can be passed to the server.
Question is whether there is any advantage/use in this case in having a (client cert); Or will the user certificate alone will suffice to trust the client as well ??
I know this is an obvious question/ but cant a rouge client application be created ?? So will the client cert protect against this scenario.
Any time you have a client server application the server needs to assume the client is compromised. When an authentication occurs (username/password, certificate, etc... it doesn't matter) the server should grant the user certain permissions to use the functionality of the server. Whenever a request is made to the server the server needs to check whether the authenticated user has the permission to perform that action.
Trusting the client to only make authorized requests opens yourself up to attacks. If you check permissions on the server and scrub inputs then you don't have to worry about whether the user is using a trusted client because even an untrusted client won't be able to do more than the trusted client could with the same authentication credentials.
These principles apply regardless of wether you are using a web client or a stand alone client. Even in a web app I can write a new client and POST data, use RESTful services, or generally talk to the web server and completely bypass the web ui you present to me.
If some attacker gets to alter in some way the client application, it could use the valid user certification to access the server.
The server should verify the client app, not for server sake (we assume the server checks if client can do this or that operation, but for ensuring the client is not being phished by a bogus client). Then the server can proclaim that all operations made by client-1 we're made through some verified client-app (agent) so they were really intended by the user.
The client application's certificate (and it's private key) can be easily ripped off the application and rogue application can be created. The ways to counteract this are (a) use user's certificate and let the user provide it when needed and (b) use a USB cryptotoken to store the client certificate and it's private key. Cryptotokens don't let the private keys out so the attacker can't copy it (though he can use the token with his application, if he has physical access to the token).