Is there any way in Java EE to know what SSL/TLS protocol is being used for a secure connection?
Ideally I want the application to use TLS/1.2 for everything, but I know some browswers (ie 9 say) by default wont support that. If I configure my enviroment to only allow TLS/1.2 then IE 9 will go "ohh this website is down", if you then click help, advance it actually tells you "oh this might be that the settings in IE disable sensible encryption, you and do this to enable sensible encryption". (I am paraphrasing slightly).
Anyway the response is a cold, "website down", which is not true, its just IE does not wish to support sensible protocols. My preference would be to change the configuration to allow weaker protocols like TLS/1.0, my application can then detect that a weak protocol is being used and on every page there can be some sort of warning "you know this is not secure, click here for more information", ie a helpful message that confirms that the website is working, just their browser is insecure. I cant see any attributes that form part of HttpServletRequest that might give me this information or any other method that answers the question.
Any thoughts?
I'm not sure if you can get the TLS protocol compatibility upfront.
How about checking for browser and its version in the request.
If any of the browsers (like you had mentioned ie) are having issues with it, then send that Warning message of yours in the response along with the actual content.
You can get the browser info using:
String userAgent = request.getHeader("User-Agent");
Also, you could probably look up some answers for achieving this using javascript. As it resides at client end, it could be used to handle such scenario's.
Related
There is a hash on the site found here. This is your fingerprint. I couldn't find how to change this fingerprint,
Here are the ways I tried;
I changed User Agent, I changed IP, but still the hash did not change in any way. On the other hand, if I log in from a different browser, it changes. How does FingerprintJS understand me in okhttp request?
PS: From my experiments, I guess the IP doesn't matter at all for fingerprint.
I'd start with using the browser developer tools like
Try that from the command line. That should show you the headers you have to send and can change.
The site shows that they use TLS details, which probably means that the TLS Version, Ciphers, and other implementation details are also relevant. You could try to change the default Ciphers to see if that changes it.
I work both on client and server. When developing, my client runs on http://localhost:3000/ while my server runs on https://local.somedomain.com. The server sends a cookie like
set-cookie: a=aB5Th....;Path=/;Expires=Sun, 02-Aug-2020 11:26:36 GMT;Max-Age=5184000
This cookie is needed for a download link looking like
https://local.somedomain.com/api/v2/ExportSomething.xlsx
however, it isn't there. As the server didn't specify a domain, it might make sense. OTOH, according to this answer, "You can't modify the cookies of one domain using a servlet or JavaScript hosted on another domain, for security reasons", and I don't want to set any cookie for any domain except the one the server runs on, so I'm asking why to specify anything when there's no choice?
Filtering "Has blocked cookies" in Chromium devtools shows nothing, which I'd interpret as "everything is fine, cookies came through". Am I wrong?
The strange thing is that it used to work one or two weeks ago, at least in Chromium (and I'm very sure about that as I worked a few hours on the export). Now it works in none of the four browsers I have tried. Any explanation?
Assuming it's necessary to specify the domain when setting the cookie, is this comment correct?
Boring details
every request sets the cookies in the same way
no requests beside the above download link use cookies
CORS is obviously needed and works and every request gets handled the same way
there are no other servers involved
Update
I've just tried cookie.setDomain("local.somedomain.com") and also this with a leading dot and it didn't help.
I also tried leaving out the Max-Age (which also removes Expires which was otherwise added automatically) and it didn't help either (someone claimed that only session cookies work on localhost).
Possible reasons for such behavior (that I can think of):
The browser settings reject all third-party cookies (if localhost receives a cookie from local.somedomain.com, that would be considered third-party)
A browser extension is blocking the cookie
The local.somedomain.com server response does not include the necessary CORS headers to allow localhost to receive the cookie. (Access-Control-Allow-Origin must be present and not set to '*', Access-Control-Allow-Credentials must be present and 'true')
Google is messing with you
That last point is actually not a joke, and most likely the cause here. Google has been tweaking the "SameSite" rules for cookies in Chromium, documented here: https://www.chromium.org/updates/same-site
An a related case on SO: Confusion regarding SameSite changes with Chrome
I'm wondering how i'd go about allowing a connection from a Java application totally bypass cloudflare for my site. I've disabled browser integrity checks for my RSS feed connections which has allowed those through, but whenever cloudflare is active, when clicking the 'Play Now' button to update the client, it'll go grey, as it should, then remain like that. No errors or 404/403 errors are printed upon it doing this, and the client will not download.
The only thing that totally resolves this is pausing cloudflare and fully disabling it for my site. I've tried adding these rules for the download url, none of which have solved it:
I think it's not possible to do it with the free plan with page rules.
Maybe you can do it by using a subdomain and disable the "Orange Cloud", so traffic will bypass any CloudFlare setting (CloudFlare will just give the IP of the server).
Or instead you can set "Security level: Off", but it's only for Enterprise Plan, and I'm not sure if you can make a Page Rule with it, because at least for the Free Plan (what I'm using) the "Off" value don't appear in the Page Rule config.
I am new to using Fiddler and I have a windows 8 metro application to be tested. I want to use fiddler to see the requests and responses from that application. I have configured fiddler by running AppContainer Loopback Exemption Utility and checking the box against my app name. Also I have unchecked all use a proxy server for my LAN (but fiddler some how checks it though) ....... Anyways I was able to see the requests sent by IE and desktop apps, but unable to see the requests of metro apps ...... Please tell me how to solve this issue
How is "java", which you tagged in your question, involved here? Metro apps are not written in Java.
Fiddler works by acting as the system's proxy. If you manually change the system's proxy configuration, Fiddler will not capture anything.
You should follow the steps described here: https://groups.google.com/forum/#!topic/httpfiddler/SsZnGxdxklg to get information which can help resolve your issue.
I am having a problem with a signed Java applet which performs simple HTTPS requests to our server (using Java's URL, Connection classes). Everything looks ok for majority of the clients. However, we do have several clients under corporate network, which are behind a proxy that requires authentication (possibly windows-logon-based authentication)). And for these clients we often hear such feedback like:
The application behaves extremely slow though our network speed is 20mbps.
20mbps connection is a huge speed for our application to work perfectly.
So my first question specifically the following:
1) Can it be the case that proxy analyses the content of our requests and thus impacts the performance of the app. And could it be only a Java-specific problem ?
The next part is about Java and Java applets specifically.
From forums I know there is a problem with Java selecting the right proxy configured in Browser. Sometimes Java applet fails to detect the proxy configured in IE, and the only solution is to configure it also in Java's Control Panel.
Having said this, the next question is:
2) Taking into account that direct connection for the corporate clients is not allowed and Java Control Panel is not properly configured, could that be the case that Java plugin selects another - wrong proxy, thru which it eventually access to the servers and thus resulting very low performance ?
I also have tried to use Apache's HttpClient (http://hc.apache.org/httpcomponents-client-ga/), to check how it performs under such environment. I have configured the client as specified in Apache tutorial to automatically get the JRE's proxy:
httpclient = new DefaultHttpClient();
ProxySelectorRoutePlanner routePlanner = new ProxySelectorRoutePlanner(
httpclient.getConnectionManager().getSchemeRegistry(),
ProxySelector.getDefault());
httpclient.setRoutePlanner(routePlanner);
And what we faced is an authentication required error (407) when we try to execute requests via Apache's httpclient. Specifically407 proxy authentication required. the ISA server requires
authorisation to fulfill the request
So the last question is about this differences between Apache and Java's client.
3) How Java Applet chooses the proxy ? and How Apache Client's selection logic differs from that of Java's ?
Please share any strongly confirmed experience you might find out could be helpful for my situation.
Thanks in advance.
3) How Java Applet chooses the proxy ?
Default behaviour:
Applet checks control panel\java\ network\network proxy settings
and uses the proxy according to the configuration in there.
Setting system properties for an applet does not works.
i.e:
System.setProperty("java.net.useSystemProxies","true");
System.setProperty("http.proxyHost", "1.1.1.1");
System.setProperty("http.proxyPort", "8080");
If you want to alter the proxy selection for an applet.
then you can use ProxySelector class.
also check out this question how-to-set-http-proxy-in-an-applet you may find it useful.