Java security issue that selfsigned sertificates will not work in next JDK release

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run the applet with using JDK 7 update 40

What is the expected output? What do you see instead?

Expected: While applet starts for the first time, a popup is shown with message 
about security issue. Checking both checkboxes fixes the problem.

Real world: It doesn't matter, how much times you start applet and check the 
SINGLE checkbox, it popups everytime the page loads.

What version of the product are you using? On what operating system?

Win7, XP
Chrome, FF, Opera
jZebra 1.5.6

Please provide any additional information below.
The next warning appears in the popup and it makes me to worry about next Java 
updates.

Original issue reported on code.google.com by vonKer...@gmail.com on 18 Sep 2013 at 12:20

Attachments:

• selfsigned_cert.jpg

[GoogleCodeExporter]

this is the message

Original comment by gonzalo....@gmail.com on 15 Oct 2013 at 9:00

Attachments:

• [Captura de pantalla 2013-10-15 a la(s) 22.58.16.png](https://storage.googleapis.com/google-code-attachments/jzebra/issue-155/comment-51/Captura de pantalla 2013-10-15 a la%28s%29 22.58.16.png)

[GoogleCodeExporter]

and this is the message when i install a certificate

Original comment by gonzalo....@gmail.com on 15 Oct 2013 at 9:04

Attachments:

• [Captura de pantalla 2013-10-15 a la(s) 23.04.11.png](https://storage.googleapis.com/google-code-attachments/jzebra/issue-155/comment-52/Captura de pantalla 2013-10-15 a la%28s%29 23.04.11.png)

[GoogleCodeExporter]

Original comment by tres.fin...@gmail.com on 15 Oct 2013 at 11:43

• Changed state: Started

[GoogleCodeExporter]

The message, in english, that is shown for the problem by gonzalo previously, 
is the image that follows.

This warning shows up the first time a page accesses the applet, and it happens 
each time.

Original comment by angel.so...@gmail.com on 16 Oct 2013 at 12:00

Attachments:

• [warning qzprint.png](https://storage.googleapis.com/google-code-attachments/jzebra/issue-155/comment-54/warning qzprint.png)

[GoogleCodeExporter]

I'm having a hard time figuring this one out... 

What I've done so far:

- Added the "all-permissions" attribute to the applet tag
- Added the "Codebase: *"  and "Permissions: *" attributes to the manifest file
- Added the "Caller-Allowable-Codebase: *" attribute to the manifest file

I also viewed the new Java verifier manifest located here:
http://www.java.com/en/download/JavaDetection.jar
http://www.java.com/en/download/JavaDetection_applet.jnlp

-Tres

Original comment by tres.fin...@gmail.com on 16 Oct 2013 at 1:42

[GoogleCodeExporter]

Lolz, this is a funny one eh Tres, I have the fix already though. java is 
really becoming a thorn in my foot i swear, i can't post tonight, but when i am 
at my office tomorrow i'll see if i can get the instructions up. If it helps 
the security is being integrated into windows now so some of the issue lies in 
java, and the other part is windows itself. talk about annoying. but rest 
assured, there are ways out of this.

Original comment by aaron.ma...@gmail.com on 16 Oct 2013 at 1:50

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Does the certificate you pay for not working either? And I am actually getting 
ready for bed. I live in texas and i have to be up at 5:30 tomorrow for a 
business presentation, sorry :/ can't talk, however, I can try to get it up at 
my lunch time on what to do. sorry i can't help now, but keep messing with 
windows/java security try taking it all completely off and building it back up 
bit by bit. We can talk tomorrow worst come to worst.

-Aaron

Original comment by aaron.ma...@gmail.com on 16 Oct 2013 at 2:37

[GoogleCodeExporter]

The certificate works just fine, but any JavaScript that accesses the applet 
creates this prompt still.

From the tutorials I'm reading, I'm doing it properly.  The main difference I 
see is Java is using a JNLP instead of <applet> tags to deploy, but that seems 
like an absurd requirement.

I'll continue trying on my own.

-Tres

Original comment by tres.fin...@gmail.com on 16 Oct 2013 at 2:45

[GoogleCodeExporter]

Hmm thats weird, I did condense down my javascript for this, i am also using it 
quite differently then how it was intended i think which is why i asked you 
about slip printing earlier.. I'll try to get in touch with you asap tomorrow 
if you don't figure it out.

-Aaron

Original comment by aaron.ma...@gmail.com on 16 Oct 2013 at 3:03

[GoogleCodeExporter]

Found it... It's actually a documented bug from the release notes of Java 7 
u45.  The recommendation doesn't look very promising, but I'll try it anyway.

----------
KNOWN ISSUES: 
(http://www.oracle.com/technetwork/java/javase/7u45-relnotes-2016950.html)
Area: Deployment/Plugin
Synopsis: Caller-Allowable-Codebase may be ignored when used with 
Trusted-Library.

If a trusted, signed jar is using the Caller-Allowable-Codebase manifest 
attribute along with Trusted-Library then the Caller-Allowable-Codebase 
manifest entry will be ignored and, as a result, a JavaScript -> Java call will 
show the native LiveConnect warning. The workaround is to remove the 
Trusted-Library manifest entry.

Original comment by tres.fin...@gmail.com on 16 Oct 2013 at 3:13

[GoogleCodeExporter]

Wow wish I would have seen that article lol. I'd expect a patch really soon 
however I think that work around is similar to something I did but I remember 
going through morenlengths because it didn't just work right away. 

Original comment by aaron.ma...@gmail.com on 16 Oct 2013 at 3:16

[GoogleCodeExporter]

Fixed with build 1.6.6 (this won't be evident for the free version unless 
you've installed the untrusted certificate from the downloads section).

Original comment by tres.fin...@gmail.com on 16 Oct 2013 at 3:47

• Changed state: Fixed

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Tres you are truly amazing!

Are then any concerns with the next JRE update, scheduled for Jan 2014 
(https://blogs.oracle.com/java-platform-group/entry/new_security_requirements_fo
r_rias) or do you think that 1.6.6 will be fine with this as well.

Original comment by dwo...@gmail.com on 16 Oct 2013 at 4:27

[GoogleCodeExporter]

Thank you for the kind words and for the bulletin.

Yes, these specific bullet points outlined in the article were addressed with 
1.6.3, however Oracle seemed to break the Trusted-Library tag in the mean time, 
so anticipating this specific bug was quite hard to forecast.

-Tres

Original comment by tres.fin...@gmail.com on 16 Oct 2013 at 4:43

[GoogleCodeExporter]

Thanks again Tres. 

Hopefully our good friends at Orcale don't stuff up the next update! I doubt it 
but we can only be cross our fingers.

Original comment by dwo...@gmail.com on 16 Oct 2013 at 4:49

[GoogleCodeExporter]

I want update a manifest file of jzebra, it's possible? i want the last version 
of jzebra for a new version java. there are any update??

thanks

Original comment by gonzalo....@gmail.com on 16 Oct 2013 at 1:11

[GoogleCodeExporter]

@Gonzalo: I used the qz-print.jar from the qz-print_1.6.6_src.zip (dist folder) 
and installed the qz-free.csr from the qz-free certs.zip as told in this 
"topic" and everything went fine afterwards. You will need to update your HTML 
code a bit though.
check post http://code.google.com/p/jzebra/issues/detail?id=155#c4 for more 
info ;)

@Tres: Would it be hard to extend your qz-free.csr to let's say 100 years 
instead of 5? I understood that it's hardcoded in the keystore of the source 
file and cannot be changed without changing the fingerprint of the jar file 
too... and I don't want to do this, otherwise I will have to do it with every 
update (generate larger cert + jar).

Many thanks in advance for your help, once again.

b0b0

Original comment by blamour...@gmail.com on 16 Oct 2013 at 1:33

[GoogleCodeExporter]

> Would it be hard to extend your qz-free.csr to let's say 100 years instead of 
5? 

@b0b0:  No its not difficult and it appears it may be possible, but it's adding 
additional validity time to to an already dangerous method of trust.

http://www.sitepoint.com/forums/showthread.php?602621-keytool-selfcert-Specifyin
g-validity-more-than-365-days-How

The trusted one we purchased is only valid for 3 years, so I'm hesitant to even 
consider this.  If there's enough demand, I can certainly create a new one.

-Tres

Original comment by tres.fin...@gmail.com on 16 Oct 2013 at 1:54

[GoogleCodeExporter]

Thanks Tres, indeed, I got you point about security. This said, being 100 years 
or 1, if there is a security issue, the matter stays the same: an update will 
be required anyway (on the applet side, or java's, or data src filtering I 
guess).

The downside of the method presented in the url you gave (which I encountered 
yesterday doing some research lol), is that it returns an error with the 
keystore presented in your source if we use your alias (jzebra I think): the 
jzebra alias already exists.
If I then decide to use another alias "jzebraca", the SHA1 footprint isn't the 
same anymore, and I would have to resign the jar file and do this everytime 
there's an update. 

So for everyone here to understand, if you want to use your own self generated 
certificate, you have to use your own signed jar file too, and the same goes 
for future jzebra (qz-print) updates (you'll have to generate the certificate 
again & sign the jar file too again).

Thanks Aaron & Tres for the explanations, all the credit goes to you guys who 
made this possible.

Now, let's see if there's "enough" demand ;)

b0b0

Original comment by blamour...@gmail.com on 16 Oct 2013 at 2:38

[GoogleCodeExporter]

Well thank you for the nice words b0b0, but give it to Tres mostly, I am just 
another programmer helping out where I can, this applet is his baby, I am just 
helping a little bit :) Go and buy his paid version and support the developer 
if you can, if not continue to spread the word about his applet, the more 
people that use it the better support will get I am sure. Also for people 
wanting to stay on update 40, you'll eventually have to take your java setting 
and turn them to medium from high, or the self signed certs won't work. I also 
do a lot of c# asp.net type programming should anyone need help integrating 
this into their software. Also my cert is for 10 years, but like tres said, its 
better to usually have it under 5. 

Original comment by aaron.ma...@gmail.com on 16 Oct 2013 at 3:05

[GoogleCodeExporter]

Also those of y'all wondering about how this method can be insecure its 
basically like this. The risks are for the client. The point of the SSL server 
certificate is that it is used by the client to know the server public key, 
with some level of guarantee that the key indeed belongs to the intended 
server. The guarantee comes from the CA: the CA is supposed to perform 
extensive verification of the requester identity before issuing the certificate.

When a client (the user and his Web browser) "accepts" a certificate which has 
not been issued by one of the CA that the client trusts (the CA which were 
embedded in Windows by Microsoft), then the risk is that the client is 
currently talking to a fake server, i.e. is under attack. Note that passive 
attacks (the attacker observes the data but does not alter it in any way) are 
thwarted by SSL regardless of whether the CA certificate was issued by a 
mainstream CA or not.

On a general basis, you do not want to train your users to ignore the scary 
security warning from the browser, because this makes them vulnerable to such 
server impersonation attacks (which are not that hard to mount, e.g. with DNS 
poisoning). On the other hand, if you can confirm, through some other way, that 
the certificate is genuine that one time, then the browser will remember the 
certificate and will not show warnings for subsequent visits as long as the 
same self-signed certificate is used. The newly proposed Convergence PKI is an 
extension of this principle. Note that this "remembered certificate" holds as 
long as the certificate is unchanged, so you really want to set the expiry date 
of your self-signed certificate in the far future (but not beyond 2038 if you 
want to avoid interoperability issues).

It shall be noted that since a self-signed certificate is not "managed" by a 
CA, there is no possible revocation. If an attacker steals your private key, 
you permanently lose, whereas CA-issued certificates still have the theoretical 
safety net of revocation (a way for the CA to declare that a given certificate 
is rotten). In practice, current Web browser do not check revocation status 
anyway. With this being said, generally you should keep the keys private, using 
Tres or Mine are fine, but you should really consider making your own and then 
assigning them out through your CA. 

-Aaron

Original comment by aaron.ma...@gmail.com on 16 Oct 2013 at 3:33

[GoogleCodeExporter]

And in addition to your points Aaron, our private key IS AVAILABLE FOR THE 
TAKING by attackers because in the nature of open source IT IS BUNDLED IN THE 
SOURCE CODE.  This is a convenience so that developers can download and build 
their own customization quickly and easily without the worry of creating a Java 
Key Store.

A better solution may be for me to create a new signature and always keep it 
private, but it would have the side effect of slowing the compile and signing 
process for new or potential Java developers.

-Tres

Original comment by tres.fin...@gmail.com on 16 Oct 2013 at 3:42

[GoogleCodeExporter]

This is quite true Tres, and you are amazing for making this open source, so 
its definitely on our end to lock things down, you have done your part in 
getting this out to us all. PS are you using JDK 1.5 or 1.7? I was wondering 
because some of the source code is asking for some dependencies or something 
from 1.5? Also hopefully java pushes out an update to fix this, I hated having 
to send an email out to clients informing them java had a bad update lol. The 
work arounds are nice and all, but god i hate doing them ya know.

-Aaron

Original comment by aaron.ma...@gmail.com on 16 Oct 2013 at 3:45

[GoogleCodeExporter]

All versions to date built with JDK 1.5.  This offers backwards compatibility 
all the way back to PPC Macintosh computers at no observable functionality loss.

If you prefer JDK 1.7, just change it in the project build properties using the 
NetBeans GUI.  It should build with no errors, but IIRC it will throw few 
warnings (i.e. JDK 6 likes the @override tag, better handling of generics, etc).

-Tres

Original comment by tres.fin...@gmail.com on 16 Oct 2013 at 3:49

[GoogleCodeExporter]

Ahh ok, well then that explains my errors, thanks for the insight. and yeah 
i've been using JDK 1.7, appreciate all the help once again, looking forward to 
see where all this take you and your company bud!

-Aaron

Original comment by aaron.ma...@gmail.com on 16 Oct 2013 at 3:50

[GoogleCodeExporter]

IMPORTANT:  It appears that this update 1.6.6. is not backwards compatible with 
older Java versions.  Testing on Java 7 u21 fails. (Because Oracle decided to 
change the behavior of "Trusted-Library").

This is very bad as it fragments compatibility with the users.  If I find a 
work-around for this, I'll send notice.

-Tres

Original comment by tres.fin...@gmail.com on 16 Oct 2013 at 5:49

[GoogleCodeExporter]

Sorry to pop in with the same request I had before, but I am currently 
upgrading to the free version of QZ Print 1.6.6, but I noticed that the 
pdf-renderer_qz.jar file from the dist/lib folder of qz-print_1.6.6_src.zip has 
a certificate signed by QZ Industries LLC, while the qz-print.jar file from the 
dist folder has a certificate signed with Tres's name. Therefore the free certs 
from "qz-free certs.zip" only works with qz-print.jar. Can the other lib files 
be updated to use the free certs too (which is currently in Tres's name)?

- Alex

Original comment by alex.b...@gmail.com on 16 Oct 2013 at 6:24

[GoogleCodeExporter]

Alex,

This is a mistake on my part, I'll have it corrected and re-uploaded later this 
evening.

-Tres

Original comment by tres.fin...@gmail.com on 16 Oct 2013 at 7:46

[GoogleCodeExporter]

I've re-uploaded 1.6.6 free version.

I'm still puzzled as to how to make this jar work across versions without an 
ugly PluginDetect.js script in the sample.html.

If you can help with this, please email me.  I'll make it worth your while.

-Tres

Original comment by tres.fin...@gmail.com on 17 Oct 2013 at 3:42

[GoogleCodeExporter]

I uploaded the pdf-renderer_qz.jar from re-uploaded 1.6.6 and I'm still getting 
Security  Warning, certificate details: QZ Industries LLC

Original comment by tero.san...@gmail.com on 17 Oct 2013 at 7:55

[GoogleCodeExporter]

Hello,

I've read this entire issue. And I don't how to thank you.

I'm also facing the problem of the 2 prompts from java, asking me to RUN and 
then to ALLOW.

I read all and I dont get very well the steps to make the prompts stop.

For now I've made the following:

1 - Downloaded the last version of qz-print from here: 
https://code.google.com/p/jzebra/downloads/detail?name=qz-print_1.6.6_src.zip&ca
n=2&q=

2 - Downloaded qz-free-certs from 
https://code.google.com/p/jzebra/downloads/detail?name=qz-free%20certs.zip&can=2
&q=

3 - went to: Control Panel > Java > Security > Manage Certs > Changed 
'Certificate Type' to 'Signer CA' > clicked 'Import' > selected 'qz-free.csr' 
from my desktop ( where is qz-free.csr and qz-free.cer )

4 - Now when I run dist/sample.html i get an error: 
java.lang.reflect.InvocationTargetException

PS. I'm using java 7u45

Thank You!

- Murilo

Original comment by murilolo...@gmail.com on 17 Oct 2013 at 1:39

Attachments:

• Capturar.PNG

[GoogleCodeExporter]

Hey Murilo,

You've added an extra level of abstraction by calling the method with 
reflection. The reflection layer wraps any exception in an 
InvocationTargetException, which lets you tell the difference between an 
exception actually caused by a failure in the reflection call (maybe your 
argument list wasn't valid, for example) and a failure within the method called.

Just unwrap the cause within the InvocationTargetException and you'll get to 
the original one.

-Aaron

Original comment by aaron.ma...@gmail.com on 17 Oct 2013 at 1:56

[GoogleCodeExporter]

Also, for anyone wondering about what it means to "unwrap the cause within the 
InvocationTargetException", I just discovered that if you've got it printed 
using exception.printStackTrace(), you just look at the "Caused By:" section 
instead of the top half/normal section.

-Aaron

Original comment by aaron.ma...@gmail.com on 17 Oct 2013 at 1:58

[GoogleCodeExporter]

@Aaron

The point is: I did not changed anything. This started to happen after i went 
to: Control Panel > Java > Security > Manage Certs > Changed 'Certificate Type' 
to 'Signer CA' > clicked 'Import' > selected 'qz-free.csr' from my desktop ( 
where is qz-free.csr and qz-free.cer ).

i Think i'm missing something to impor the certificate. Because i did nothing 
with the qz-free.cer

Original comment by murilolo...@gmail.com on 17 Oct 2013 at 2:10

[GoogleCodeExporter]

@Murilo

You need to import the file that has the file extension .csr, you dont even 
need the .cer files. Just the .csr file. Also make sure you have the correct 
.jar file that the certs are signed too. Not sure if the source code has that, 
so when you compile it into a .jar you need to then sign it with the .cer file, 
then convert it into a .csr file then import it, that way you know your .jar 
file is signed with the right cert. 

Also what I told you to do there will tell you what your problem is, I know you 
didn't touch the file, but narrowing down your problem will help you, or us if 
you can tell us more. The reflection error you are getting needs to be 
unwrapped if messing with the cert stuff doesn't work. Hope this helps

-Aaron

Original comment by aaron.ma...@gmail.com on 17 Oct 2013 at 2:16

[GoogleCodeExporter]

OK Now I understand.

Probably the .jar that i've downloaded is not compatible with the certs I've 
downloaded. How do i sign a .jar with a .cer to obtain a valid .csr ?

Original comment by murilolo...@gmail.com on 17 Oct 2013 at 2:26

[GoogleCodeExporter]

That is one possibility yeah, I'd still try to unwrap that method that's 
throwing that error to be sure, but I created a document on to create and sign 
.jar with your own certs, but you need to have some basic knowledge with 
jarsigner and keytool applications in your java sdk. I have attached the 
document explaining how to do it. good luck

-Aaron

Original comment by aaron.ma...@gmail.com on 17 Oct 2013 at 2:33

Attachments:

• signedcertsforscripts.docx

[GoogleCodeExporter]

I'm also having trouble with the pdf-renderer_qz.jar file saying it's signed by 
QZ Industries LLC.  Is the csr available for that one?  I tried resigning it 
with the qz.ks in the qz-print directory and it gets "jarsigner: 
java.lang.SecurityException: cannot verify signature block file 
META-INF/JZEBRA" when I run verify on it.

Original comment by ke...@kjordan.net on 17 Oct 2013 at 3:52

[GoogleCodeExporter]

@Murilo: stupid question: but have you tried to close all instances of java.exe 
(guessing you are using windows here), or all instances of all browsers before 
trying again? I noticed that Java doesn't behave correctly with my firefox as 
long as I do not do this ... (I have the exact same setup as yours)

b0b0

Original comment by blamour...@gmail.com on 17 Oct 2013 at 4:35

[GoogleCodeExporter]

Regarding Murilo's first post, I had the same error with sample.html doing the 
same steps. However if I copied the same jar file for use in my own existing 
project's web page, I got no errors. So I think there is a problem in 
sample.html. Also loading.html doesn't work either. However I found no problem 
with using qz-print.jar file itself outside of the sample web pages.

-Alex

Original comment by alex.b...@gmail.com on 17 Oct 2013 at 5:17

[GoogleCodeExporter]

@murilolobatto,

Just run it from an http or https location and it will be fine.  The new 
version blocks trusted signed apps from file:// but ironically allows untrusted 
signed apps so you can no longer run the demo from your desktop after 
installing the certificate.

-Tres

Original comment by tres.fin...@gmail.com on 17 Oct 2013 at 5:55

[GoogleCodeExporter]

Oracle has acknowledged this issue:
https://blogs.oracle.com/java-platform-group/entry/7u45_caller_allowable_codebas
e_and

  > "This will be fixed in a future release so that both attributes can co-exist."

Original comment by tres.fin...@gmail.com on 18 Oct 2013 at 10:24

[GoogleCodeExporter]

Some satire:
http://tinyurl.com/javabroke

Original comment by tres.fin...@gmail.com on 19 Oct 2013 at 5:10