I have installed Java 9 because I want to use the OCSP (Online Certificate Status Protocol) feature with the TLS handshake, aka OCSP stapling. As https://docs.oracle.com/javase/9/security/java-pki-programmers-guide.htm#JSSEC-unique_4307382 states, Java 9 is the first edition to make use of OCSP stapling.
To test it, you can set or read certain new properties, such as "jdk.tls.server.enableStatusRequestExtension".
However, I get "null" instead of "false" (or "true") when querying this property with
System.getProperty("jdk.tls.server.enableStatusRequestExtension")
Just tried it out with the new jShell:
[jshell> System.getProperty("jdk.tls.server.enableStatusRequestExtension")
$2 ==> null
This is not supposed to happen with Java 9. Any ideas why? It is a so-called Early Access build which I downloaded two days ago. The official release of Java 9 is September 21st 2017 (yesterday). Unfortunately, there is no released version out yet for Mac OSX.
Could it really be that this feature is not yet implemented in the Early Access Build (which is supposed to be close to the final release)?
Hope anyone can help here.
jshell returns null for your call to System.getProperty("jdk.tls.server.enableStatusRequestExtension") because that property does not exist. I get the same result under Java 9.
You seem to expect that property to automatically exist under Java 9 but that is not the case; you still need to explicitly create it, and assign it a value of "true". From JEP 249, that implemented this feature in Java 9:
The implementation will choose reasonable defaults for OCSP specific parameters, and will provide configuration of these defaults via the
following system properties...
That doesn't mean that all of the OCSP properties automatically exist in Java 9 with default settings; it means that in the absence of those OCSP System properties the code will "choose reasonable defaults". For example, if the server cannot read the property jdk.tls.server.enableStatusRequestExtension the implementation will (reasonably) behave as though the property had been set with a value of "false".
See also this code example for OCSP from an Oracle presentation on security:
// Enable OCSP Stapling (off by default)
System.setProperty(“jdk.tls.server.enableStatusRequestExtension”, “true”);
// Yes, that’s really it!
So I suggest that you just explicitly set your client and server properties for OCSP as necessary, and don't worry about them not already existing under Java 9.
TLDR version: Java 9 supports OCSP stapling for TLS, but assumes that it is not enabled in the absence of any explicit configuration from the user.
Related
I think its a theoratical Question. I have a project on dotnet framework 4.5 and what i need to do is that whenever a client is using older httpversion i have to redirect it to an error page.
i am getting http version like this
var d = Request.ServerVariables["SERVER_PROTOCOL"];
and it is giving value "HTTP/1.1". I think this is the http version of Request. Right? now my Question is
//
CASE 1) do we have to set http version on server and compare our server version with the version that we get from Request.ServerVariables["SERVER_PROTOCOLS"] OR
//
CASE 2) i have to compare it with latest http version(which is showing HTTP/2 on google) via a simple string comparison
var d = Request.ServerVariables["SERVER_PROTOCOL"];
if(d=="HTTP1.1") //"HTTP/2 either of which is latest"
{}
if its the CASE 1 then how do we set http version of our server and if it CASE 2 then what if later httpversion changes to "HTTP/3" then do i have to go to code again and change the condition for latest httpversion
I am getting http version like this
var d => Request.ServerVariables["SERVER_PROTOCOL"];
and it is giving value
"HTTP/1.1". I think this is the http version of Request. Right?
Yes
Do we have to set http version on server and compare our server
version with the version that we get from
Request.ServerVariables["SERVER_PROTOCOLS"]
It is totally up to you what version you want to support. If you want to support min
HTTP/2 then create a config value on the server: MinHttpVersion = 2
Problems with the above approach
I don't know why you are doing this but seems like a strange requirement and you may run into some SEO related issues:
Bots/Crawlers: you need to differentiate users from crawlers. Crawlers don't necessarily use a flash browser and this way, you may end up blocking them. You need to detect crawlers and exclude them from any version requirement.
Redirection to error page: This is not an error situation and should not be redirected to an error page. The redirect is a poor user experience (increases the page load time) and will cost your website in SEO ranking.
Better approach
It is not clear why you want to do this? I suspect you don't want to support older browsers? If that's the case, then the common approach is to check user's browser version. For example this is what happens when you open Stackoverflow in IE:
So, you need to decide what is the minimum version for each browser that you want to support. Then you need to detect user's browser and if it's too old show an "outdated browser" message (do not redirect to an error page) and make sure you exclude crawlers.
You can do this both on the server and client side. This library might give you some ideas.
I'm seeing the following pair of errors in eventvwr on Windows Server 2008 R2:
An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed.
Source is Schannel, Event ID is 36874.
The following fatal alert was generated: 40. The internal error state is 1205. Source is Schannel, Event ID is 36888. I know this second error is basically just saying the TLS handshake failed which is what the previous error is saying too.
I can make these errors occur intentionally by using sslscan, for example if I run sslscan.exe --tls12 --verbose [myserver].com:443, I see a list of accepted ciphers followed by this error: SSL_get_error(ssl, cipherStatus) said: 5
Each time I run this I get two pairs of errors in the eventvwr, but I don't know why or which ciphers are at issue. It says the SSL certificate is weakly encrypted (it's using sha1RSA), which I can fix, although I don't know if that's related to the TLS errors or not.
I've seen other similar questions whose response is usually "disable schannel logging in the registry to hide the error", but that's not a fix, so I'm reluctant to do that.
EDIT:
I also asked this question here: https://learn.microsoft.com/en-us/answers/questions/275585/tls-12-error-schannel-event-id-36874-and-36888.html
There is a blog post which I believe may hold the answer, here: https://blog.ittoby.com/2014/07/why-schannel-eventid-36888-36874-occurs.html
If I'm able to resolve the issue based on this, I'll add an answer to this question with what worked for me.
I’m trying to access an endpoint, which requires a client cert.
I’m starting from a .p12, which I was able to quickly import to Google Chrome, and can successfully access the endpoint. So the client certificate and endpoint are compatible.
However, I’m struggling to get Python Requests module (with Python 2.7) to successfully access the same endpoint.
My steps have been:
openssl pkcs12 -in my.p12 -out certificate.pem –nodes prompts me for a password, then creates certificate.pem
print(requests.get("<https://endpoint>", cert="certificate.pem").content) returns You don't have permission to access "http" on this server. (and a HTTP response of 403)
My PEM file contains three sets of -----BEGIN CERTIFICATE-----, and then -----BEGIN PRIVATE KEY-----.
All 4 BEGINs are preceded by Bag Attributes – removing these lines doesn’t make a difference.
I'm doing the key creation with a Ubuntu VM, but running the Python from a Windows machine - not sure if this makes a difference.
I’d welcome any ideas; particularly to understand if the issue is around the conversion to PEM, or if it’s with the request call.
The error is not indicative of a problem with the client certificate.
If your client certificate were the problem the documentation suggests your error would have been prefixed with "SSLError": http://docs.python-requests.org/en/master/user/advanced/#client-side-certificates
The relevant error is likely in the part you are censoring for privacy reasons. Having achieved authentication, the web server is rejecting your request for some other reason.
Possibly you are calling requests.get('https://website.com', ...
You may need to call requests.get('https://website.com/', ...
Or directly request a file resource within the website. When testing with Chrome, a non-displayed trailing '/' may have been used when Chrome made the request to the web server. Try adding / to the end of the address.
Certainly you shouldn't be using the "<" ">" tags shown in your example.
I found https://gist.github.com/erikbern/756b1d8df2d1487497d29b90e81f8068, with the delete=False param as suggested in those comments, and pyOpenSSL, now works.
The RFC states:
10.4.6 405 Method Not Allowed
The method specified in the Request-Line is not allowed for the
resource identified by the Request-URI. The response MUST include an
Allow header containing a list of valid methods for the requested
resource.
However, I've been unable to identify a single server which complies with that MUST.
I can see that that requirement would be very hard to fulfill with modern web servers, given the variety of proxying, dynamic applications, etc that exist.
Why, historically, did that requirement make sense?
Does anything depend on that behavior, or did it ever? What would a use case for it be?
Do any web servers "properly" implement this aspect of http? IIS (at least when using ASP.NET) and even some "RESTful" APIs return 404 rather than 405 when giving a bogus method, as far as I've been able to tell.
Additionally, why do servers return 405 for methods such as BOGUS that clearly are not implemented by the server, even when serving documents and not proxying out or calling some code (cgi/etc), when they should return 501?
Should these parts of HTTP be considered "vestigial", seeing as few if any servers conform to the spec?
Actually, it isn't that hard for most frameworks to properly return 'Allow'. All of the frameworks I know of require specification of which methods a specific controller is going to be called for (usually defaulting to GET), and code could easily register extension methods with the framework for it to return.
So far the evidence seems to point to either a) nobody reads the spec and nobody knows about this requirement, b) nobody cares about this feature.
Trying to directly answer the questions:
The requirement still makes sense, especially - as Meryn's comment says for HATEOAS API's.
Since a server is "An application program that accepts connections in order to service requests by sending back responses" it's easy to say yes - there are applications on the net that depend on it. ;) One such use case is to respond 405 to a POST /resource/1/ with Allow: GET, HEAD, PUT, DELETE to indicate the resource is not a "factory resource".
Since the methods allowed on a resource could vary by application logic, we should also consider application servers - as you point out in your question. In which case, yes - e.g., django returns a proper Allow header with 405 responses.
Is it possible to use the flash.net.NetConnection object to connect to my Flash remoting enabled web application over HTTPS within Tomcat or any other servlet container?
I am using the SpiceFactory cinnamon project for amf remoting and have searched for examples of using HTTPS but see only the reference to a proxy type in the NetConnection object.
If someone could provide a reference or example that would be awesome. Or if it is not possible using the flash.net.NetConnection object are there any recommendations of how to configure HTTPS for the spicefactory cinnamon library.
According to the creator Jens Halm, it should just work out of the box.
http://www.spicefactory.org/forum/viewtopic.php?t=407
flex https works fine , if you use self signed certificate end user needs to add the public key manually to the trusted store, by directly connecting to the site using https://...
and accept the certificate.
second way is run the connection over http and do the encryption / description manually using
as3crypto - flex http://code.google.com/p/as3crypto/ and php openssl