Java and "unsigned" applications

Since the most recent update, Java no longer allows you to permanently disable warnings about this on sites you know and trust. That by itself is merely irritating.

However, more ominously, the warning now says:

Running unsigned applications like this will be blocked in a future release because it is potentially unsafe and a security risk.

What does this mean? "Blocked", as in you will no longer have the option to say: "I know, and I accept the risk"?

Several sites I've used for years without incident are triggering the warning. At some point, will these sites become useless to me - and most other people? Or have I misunderstood?

I do take security seriously, but it will certainly have a detrimental impact on user experience if Java blocks without possibility of override any site that might possibly present a security risk - even those that have been used and trusted for years.

I realise they may well be trying to force site administrators to cough up for certificates (am I right in assuming these are NOT free?) or see their sites rendered useless to the vast majority of visitors (all who regularly update Java).

It seems this will hit small, non-commercial hobby and special-interest sites the hardest, because they won't have a budget for certificates. It is already that kind of site that is prompting the warnings - not the commercial big boys.

This looks as if it is going to break a lot of neat little not-for-profit sites.

T.

In reply to a post by TLM:

I realise they may well be trying to force site administrators to cough up for certificates (am I right in assuming these are NOT free?) or see their sites rendered useless to the vast majority of visitors (all who regularly update Java).

Code signing certificates signed by a root in the Java certificate bundle are pretty expensive.


There are inexpensive sources of code signing certificates - StartSSL Verified, which costs US$59.90, allows you to issue as many 2 year validity certificates as you need for 350 days, including wild card server certificates and code signing certificates. You pay once for the validation, not per certificate.

There are limitations on a StartSSL Verified code signing certificate - there's an OID that prevents the signature from being valid on Windows after the certificate expires (even if the signature was time stamped during the certificate's validity, which normally prevents signature expiry), also you can't sign Windows kernel code with a StartSSL Verified certificate. These restrictions are lifted if you have Extended Verification, but that requires you to be a bona fide business or incorporated organisation.


StartSSL's root is in all the major browsers and operating systems. However, from previous conversations with Eddy Nigg who runs StartSSL, it's not cost effective to get StartSSL's root into Adobe's PDF software or Java - Adobe and Oracle wanted a sizeable amount of money to include the root and I believe wanted per-certificate royalties. You can add StartSSL's root to your own Adobe PDF or Java installation if you wish, but the signatures will not verify on a standard installation.


I guess it shows I'm a huge fan of StartSSL. If you want a 1 year client or server certificate, it's free of charge, so even hobby servers and network devices can use 'proper' certificates. My router and wireless access point have StartSSL certificates for their configuration GUIs!



There's a huge risk in Oracle's approach. Whilst the move to limiting unsigned applications is welcome considering all the security incidents relating to Java in recent times, requiring every application to be signed risks sloppy signing practices.

Most organisations only sign final releases after appropriate code review and security checks - there's a defined procedure to be followed to make a release, and only a limited number of people have access to the code signing certificate.

The correct approach if all applications have to be signed is to generate your own local CA and certificates, and add the CA to the Java certificate store on your development machines. The risk is that instead of doing this, organisations will sign every test build with a 'proper' code signing certificate. After all, a code signing certificate merely allows you to identify whose certificate signed the code - it says nothing about the quality or security of that code, or even if that certificate is still under the sole control of the individual or organisation it was issued to (he says, looking at the security tokens that contain his client and code signing certificates).


The other risk, which is potentially more serious, is that people will get so fed up with all the unsigned application warnings that they revert to a version of Java without the warnings and stop updating.

Thanks, but I'm not a site-developer, so I'm sort of coming to it from the other angle.

It seems probable most small, non-profit sites won't have the time or money to devote to this, so is it really the case that Oracle intend to stop all those sites working, rather than just make users "accept" the risks? I would certainly be among those tempted to disable Java updates, if they're going to break innocuous sites I've used for years without incident.

I know that is not the way forward, but neither is just accepting I can't use many of my favourite sites any more.

T.

Will the very useful http://www.dslreports.com/tweaks be blocked by Java, looks like it?

I was trying to explore the issues in terms of certificate availability - not least as there are still people who are unaware of the availability of free and inexpensive certificates that chain to roots in the majority of root bundles.

Looking at the StartCom forums, it looks as if there is the possibility of StartSSL's root being added to the Java certificate bundle, but it's being held up for some sort of internal reason within Oracle. If this root is added, individual developers would have the option of getting a suitable code signing certificate, and as many server certificates as they need, for US$59.90 every two years. US$30/year is hopefully within the reach of most hobby developers. StartSSL's philosophy is to provide the cheapest possible digital certificates to the Internet community, and only to charge for the work they do, not for automated issuing of a certificate. I have no connection with them other than as a satisfied customer.

The majority of code signing certificate providers want much more money. SSL Shopper imply most issuers want US$200 per year, and many issuers will only issue code signing certificates to bona fide organisations, not individuals.


As you rightly say, the risk is that applets on legitimate and valuable sites will stop working for those users who keep Java up to date. Oracle's proposed change in the Java security model clearly involves an unacceptable security sacrifice: users would not be able to accept the potential risk of an unsigned Java application on a current version of Java, but must instead accept the much bigger risk of running all Java applications, signed or not, on an obsolete version of Java with known security risks.

Talk about an own goal - it's been hard enough to get people to update Java, and now Oracle are giving users a firm reason to stop updating now to avoid a badly thought out proposed future change.

Edited by David_W (Tue 29-Oct-13 15:34:21)

In reply to a post by 4M2:

Will the very useful http://www.dslreports.com/tweaks be blocked by Java, looks like it?

As things currently stand, yes, but I'd expect a site with the resources of dslreports.com to be able to afford a code signing certificate and sign the applications.