TLS problems
Christian
hopefully someone has an idea...
When creating a TLS connection using a SSLEngine with Diffie Hellmann as
algorithm I do get the following error..
i.e. TLS_DHE_RSA_WITH_AES_128_CBC_SHA" gives error
while TLS_RSA_WITH_AES_128_CBC_SHA works fine ...
Any idea what I could do?
regards
Christian
java.lang.RuntimeException: Could not generate DH keypair
at com.sun.net.ssl.internal.ssl.Handshaker.checkThrown(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.checkTaskThrown(Unknown
Source)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.readNetRecord(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.unwrap(Unknown Source)
at javax.net.ssl.SSLEngine.unwrap(Unknown Source)
at uc.protocols.UnblockingConnection.unwrap(UnblockingConnection.java:343)
at
uc.protocols.UnblockingConnection.evaluateHandshakeStatus(UnblockingConnection.java:326)
at
uc.protocols.UnblockingConnection.access$9(UnblockingConnection.java:290)
at uc.protocols.UnblockingConnection$4.run(UnblockingConnection.java:320)
at uc.DCClient$1.run(DCClient.java:168)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.RuntimeException: Could not generate DH keypair
at com.sun.net.ssl.internal.ssl.DHCrypt.<init>(Unknown Source)
at
com.sun.net.ssl.internal.ssl.ClientHandshaker.serverKeyExchange(Unknown
Source)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(Unknown
Source)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown Source)
at com.sun.net.ssl.internal.ssl.Handshaker$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.net.ssl.internal.ssl.Handshaker$DelegatedTask.run(Unknown
Source)
at uc.protocols.UnblockingConnection$4.run(UnblockingConnection.java:316)
... 4 more
Caused by: java.security.InvalidAlgorithmParameterException: Prime size
must be multiple of 64, and can only range from 512 to 1024 (inclusive)
at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DashoA13*..)
at java.security.KeyPairGenerator$Delegate.initialize(Unknown Source)
... 12 more
Thomas Pornin
> When creating a TLS connection using a SSLEngine with Diffie Hellmann as
> algorithm I do get the following error..
> i.e. TLS_DHE_RSA_WITH_AES_128_CBC_SHA" gives error
> while TLS_RSA_WITH_AES_128_CBC_SHA works fine ...
> java.lang.RuntimeException: Could not generate DH keypair
> Caused by: java.security.InvalidAlgorithmParameterException: Prime size
> must be multiple of 64, and can only range from 512 to 1024 (inclusive)
> at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DashoA13*..)
> at java.security.KeyPairGenerator$Delegate.initialize(Unknown Source)
> ... 12 more
I am assuming that your failing code is a TLS client.
In TLS, when using a DHE cipher suite, the server computes an
ephemeral Diffie-Hellman key pair, sending the public part to the
client. The server uses its own non-ephemeral private key (a RSA
key) to _sign_ that DH public key.
The DH public key includes a definition of the group in which DH
is computed, namely a prime modulus p and a base value g (a number
modulo p such that the multiplicative subgroup generated by g has
an order which is divided by a big enough prime). The client must,
by definition, compute its own DH key pair within the same group.
The TLS code from Sun relies on the "generic" DH key pair generator
which is included in the same provider. That implementation has some
limitations on which values p could take; namely, it requires that the
length of p (in bits) is a multiple of 64, is no less than 512, and no
more than 1024. These restrictions relate to rather old regulatory
prescriptions from the US government (the same restrictions applied on
older versions of the related DSS signature algorithms). Note that even
the 2001 version of ANSI X9.42 (which standardizes Diffie-Hellman)
accepts other lengths (in X9.42, length of p must be a multiple of 256,
no less than 1024, with no upper limit).
To sum up: the TLS server is using DH parameters (the DH modulus and base)
that the TLS client cannot cope with. Arguably, the TLS client (Sun's
provider) is at fault here, since it does not implement the last ten
years of standards. However, it will probably be simpler for you to
configure the TLS _server_ to use DH parameters with a 1024-bit DH
modulus. But beware: 1024 bits are nowadays considered to be "a bit
short" for security with DH (no actual break, but many institutions, in
particular banks, tend to think that the safety margin is too small
with such a size).
--Thomas Pornin
Roedy Green
quoted or indirectly quoted someone who said :
>When creating a TLS connection using a SSLEngine with Diffie Hellmann as
>algorithm I do get the following error..
>i.e. TLS_DHE_RSA_WITH_AES_128_CBC_SHA" gives error
>while TLS_RSA_WITH_AES_128_CBC_SHA works fine ...
>
>Any idea what I could do?
not everything that logically should be supported is. See
http://mindprod.com/jgloss/jce.html
for a little program to enumerate what is available on any given
platform.
--
Roedy Green Canadian Mind Products
http://mindprod.com
"For reason that have a lot to do with US Government bureaucracy, we settled on the one issue everyone could agree on, which was weapons of mass destruction."
~ Paul Wolfowitz 2003-06, explaining how the Bush administration sold the Iraq war to a gullible public.
Roedy Green
quoted or indirectly quoted someone who said :
>To sum up: the TLS server is using DH parameters (the DH modulus and base)
>that the TLS client cannot cope with. Arguably, the TLS client (Sun's
>provider) is at fault here, since it does not implement the last ten
>years of standards. However, it will probably be simpler for you to
>configure the TLS _server_ to use DH parameters with a 1024-bit DH
>modulus. But beware: 1024 bits are nowadays considered to be "a bit
>short" for security with DH (no actual break, but many institutions, in
>particular banks, tend to think that the safety margin is too small
>with such a size).
If you install the USA extensions, does that limit expand?
http://java.sun.com/javase/technologies/security/#UnlimitedDownload
Thomas Pornin
> If you install the USA extensions, does that limit expand?
I doubt it. The "USA extensions" were part of compliance to the US
export regulations, which e.g. forbade export of software which allowed
RSA encryption with a key longer than 512 bits. In order to make the
SunJCE provider exportable, Sun embedded a policy check mechanism: the
provider limits the size of the keys it supports, based on the
permissions obtained in a "policy file" which is part of a signed Jar.
The "USA extensions" are such a signed Jar, which removes any
restriction.
At some time in the late Clinton era (i.e. around 1999 or 2000), the US
export restrictions were lifted, to the effect that Sun could export the
unrestricted SunJCE provider as it saw fit. The "US export" and the
"local" signed Jar are now identical, so installing the USA extensions
is now just a convoluted way of doing nothing.
--Thomas Pornin
(There may be some restrictions at some point, but not related to
"export from the USA". Rather, restrictions on "export to North Korea".
For any programmer with a computer and an Internet access, who downloads
the JRE from Sun, chances are that he got the complete, unrestricted
crypto version.)
Christian
> According to Christian <fake...@xyz.de>:
>> When creating a TLS connection using a SSLEngine with Diffie Hellmann as
>> algorithm I do get the following error..
>> i.e. TLS_DHE_RSA_WITH_AES_128_CBC_SHA" gives error
>> while TLS_RSA_WITH_AES_128_CBC_SHA works fine ...
> [...]
>> java.lang.RuntimeException: Could not generate DH keypair
> [...]
>> Caused by: java.security.InvalidAlgorithmParameterException: Prime size
>> must be multiple of 64, and can only range from 512 to 1024 (inclusive)
>> at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DashoA13*..)
>> at java.security.KeyPairGenerator$Delegate.initialize(Unknown Source)
>> ... 12 more
>
> I am assuming that your failing code is a TLS client.
>snip
>
>
> To sum up: the TLS server is using DH parameters (the DH modulus and base)
> that the TLS client cannot cope with. Arguably, the TLS client (Sun's
> provider) is at fault here, since it does not implement the last ten
> years of standards. However, it will probably be simpler for you to
> configure the TLS _server_ to use DH parameters with a 1024-bit DH
I actually have no control over servers.. as this tool must operate with
numerous implementations... especially this error happened to me in
interoperation with some c++ software that used OpenSSL lib
> modulus. But beware: 1024 bits are nowadays considered to be "a bit
> short" for security with DH (no actual break, but many institutions, in
> particular banks, tend to think that the safety margin is too small
> with such a size).
>
>
> --Thomas Pornin
would using some other provider like may be "bouncycastle" solve that
problem? Or are there other solutions?
about roedy ... Unlimmited strength jurisdiction file did not change a
thing (except AES256 also being available).. though may be I
misunderstood you ..
christian
Thomas Pornin
> would using some other provider like may be "bouncycastle" solve that
> problem?
Possibly. It is worth a try.
--Thomas Pornin
Christian
it was worth a try.. actually just installing the new provider via
Security.addProvider(provider)
seems to have had no effect..
though by using
Security.insertProviderAt(new BouncyCastleProvider(),1);
I at least get a different exception... any hints welcome..
java.lang.RuntimeException: 64
at com.sun.net.ssl.internal.ssl.Handshaker.checkThrown(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.checkTaskThrown(Unknown
Source)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.writeAppRecord(Unknown
Source)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.wrap(Unknown Source)
at javax.net.ssl.SSLEngine.wrap(Unknown Source)
at uc.protocols.UnblockingConnection.send(UnblockingConnection.java:172)
at
uc.protocols.UnblockingConnection.evaluateHandshakeStatus(UnblockingConnection.java:309)
at
uc.protocols.UnblockingConnection.access$9(UnblockingConnection.java:290)
at uc.protocols.UnblockingConnection$4.run(UnblockingConnection.java:320)
at uc.DCClient$1.run(DCClient.java:202)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 64
at com.sun.crypto.provider.TlsPrfGenerator.expand(DashoA13*..)
at com.sun.crypto.provider.TlsPrfGenerator.doPRF(DashoA13*..)
at com.sun.crypto.provider.TlsPrfGenerator.doPRF(DashoA13*..)
at
com.sun.crypto.provider.TlsMasterSecretGenerator.engineGenerateKey(DashoA13*..)
at javax.crypto.KeyGenerator.generateKey(DashoA13*..)
at
com.sun.net.ssl.internal.ssl.Handshaker.calculateMasterSecret(Unknown
Source)
at com.sun.net.ssl.internal.ssl.Handshaker.calculateKeys(Unknown Source)
at
com.sun.net.ssl.internal.ssl.ClientHandshaker.serverHelloDone(Unknown
Andreas Wollschlaeger
> Hello,
>
> hopefully someone has an idea...
>
> When creating a TLS connection using a SSLEngine with Diffie Hellmann as
> algorithm I do get the following error..
> i.e. TLS_DHE_RSA_WITH_AES_128_CBC_SHA" gives error
> while TLS_RSA_WITH_AES_128_CBC_SHA works fine ...
>
> Any idea what I could do?
>
> regards
> Christian
>
Not sure if any of the other elaborated answers included this, but: Have
you installed the "Java Cryptography Extension (JCE) Unlimited Strength
Jurisdiction Policy Files", e.g. at
http://java.sun.com/javase/downloads/index.jsp at the very bottom of the
page... Oddly this is still a separate download in 2009 :-(
HTH
Andreas
Christian
They were my first guess though didn't change anything..
Lew
> Not sure if any of the other elaborated answers included this, but: Have
> you installed the "Java Cryptography Extension (JCE) Unlimited Strength
> Jurisdiction Policy Files", e.g. at
> http://java.sun.com/javase/downloads/index.jsp at the very bottom of the
> page... Oddly this is still a separate download in 2009 :-(
Oddly, it's still illegal to rob a convenience store in 2009.
Point being that they have to comply with the law. This is explained in the
README.txt file that comes with the stronger policy files.
The law may be odd, but that isn't Sun's fault.
--
Lew
Christian
or changeing SSLContext creation parameter from TLS to TLSv1 ...
Christian
just no longer appearing that often.. and only when being Client and not
Server
Roedy Green
quoted or indirectly quoted someone who said :
>hmm problem seems to be still there...
>just no longer appearing that often.. and only when being Client and not
>Server
Is there some sort of protocol-sniffing tool that lets you sort out
problems like this for SSL? Or is that a self-contradictory request?
I would think such a tool would need to get its hooks in quite deep,
not just look at packets swimming by.
Roedy Green
quoted or indirectly quoted someone who said :
>Andreas Wollschlaeger wrote:
Thomas Pornin, who seems unusually knowledgeable on JCE, said the law
was repealed circa 2000. I don't recall that happening. I would have
expected it to have come up since the law was so idiotic.
If it was repealed, why is the download still there?
Anyone got a link to the official story?
Thomas Pornin
> Point being that they have to comply with the law. This is explained
> in the README.txt file that comes with the stronger policy files.
The oddity lies in the apparent uselessness of the "stronger policy
files" since the plain JDK _already_ comes with the ability to use
arbitrary key lengths with RSA. Installing the "stronger policy files"
looks like just a convoluted way of doing nothing at all.
For instance, download a plain JDK-1.6.0_14 from Sun, preferably from
a machine which is located outside of the US, in case Sun would
automatically alter the downloaded file based on the country from which
the request comes. Then run the following program:
// ========================================================================
import java.security.interfaces.*;
import javax.crypto.*;
public class TestRSA {
public static void main(String[] args)
throws Exception
{
KeyPairGenerator kpgen =
KeyPairGenerator.getInstance("RSA");
kpgen.initialize(2048);
KeyPair kp = kpgen.genKeyPair();
PublicKey pk = kp.getPublic();
PrivateKey sk = kp.getPrivate();
System.out.printf("got RSA key, length=%d\n",
((RSAPrivateCrtKey)sk).getModulus().bitLength());
Cipher menc = Cipher.getInstance("RSA/ECB/PKCS1Padding");
menc.init(Cipher.ENCRYPT_MODE, pk);
menc.update("Hello World !".getBytes("UTF-8"));
byte[] ct = menc.doFinal();
Cipher mdec = Cipher.getInstance("RSA/ECB/PKCS1Padding");
mdec.init(Cipher.DECRYPT_MODE, sk);
mdec.update(ct);
byte[] pt = mdec.doFinal();
System.out.printf("plaintext = '%s'\n",
new String(pt, "UTF-8"));
}
}
// ========================================================================
That program generates a 2048-bit RSA key pair, encrypts a message with
the public key, then decrypts it with the private key. I tried this on a
plain JDK-1.6.0_14, newly downloaded from Sun's website from a machine
located in France (i.e. really outside of the US, and, I daresay, "more"
outside than, say, Canada or Mexico). The program above runs like a
charm.
However, the "stronger policy files" do have an effect, not on asymmetric
algorithms such as RSA, but on symmetric encryption algorithms. For
instance, with the newly downloaded JDK, one can encrypt symmetrically
with AES and a 128-bit key, but _not_ with a 192-bit of 256-bit key.
Installing the "stronger policy files" unlocks those extra key lengths.
This is still an oddity, since AES with a 128-bit key is already as
strong as one could wish (i.e. it is far advanced in the realm of
"mankind cannot break it now nor in the foreseeable future" in which
strength distinctions about key lengths are somewhat difficult to merely
define, let alone measure). Yet, this is not an oddity of Sun, rather an
oddity of the law (and, as far as I can see, this is not a US-only
oddity either). Speaking of which, the mere existence of three standard
key lengths for AES (128, 192 and 256 bits) is in itself an oddity which
stems from some US (military) regulatory requirements, which call for
three "distinct" levels of protection, under the assumption that a truly
unbreakable algorithm is necessarily expensive, and thus a relaxed mode
is called for (that assumption originates from the 1930s, before the
invention of the computer, but outdate military regulations are quite
hard to kill). Since 128 bits already provide unbreakable encryption
(with regards to nowadays technology), longer keys are not needed, but
they do exist, and they are import/export-regulated.
For much information on the laws about cryptography in various
countries, see:
http://rechten.uvt.nl/koops/cryptolaw/
For export from the United States, key lengths and algorithms are
unlimited, except that the US governments insists on a "technical
review" which is limited in time (basically, the US government wishes to
remain aware of what cryptographic tools exist and cross borders). Also,
there are special (and drastic) restrictions when the export is towards
one of the following seven countries: Cuba, Iran, Iraq, Libya, North
Korea, Sudan, and Syria (note that the list of "terrorist countries"
includes Iraq but not Afghanistan). Import laws of some countries
(for instance France) apply some restrictions on the import of
symmetric keys longer than 128 bits.
In Sun's JDK, lookup the contents of the jre/lib/security/local_policy.jar
and jre/lib/security/US_export_policy.jar files. These files define
the rules that Sun's JCE provider follows; these are the files that
the "stronger policy files" (jce_policy-6.zip) replace. In particular,
the "local_policy.jar" contains this file:
// Some countries have import limits on crypto strength. This policy file is worldwide importable.
grant {
permission javax.crypto.CryptoPermission "DES", 64;
permission javax.crypto.CryptoPermission "DESede", *;
permission javax.crypto.CryptoPermission "RC2", 128,
"javax.crypto.spec.RC2ParameterSpec", 128;
permission javax.crypto.CryptoPermission "RC4", 128;
permission javax.crypto.CryptoPermission "RC5", 128,
"javax.crypto.spec.RC5ParameterSpec", *, 12, *;
permission javax.crypto.CryptoPermission "RSA", *;
permission javax.crypto.CryptoPermission *, 128;
};
whereas the "stronger" file of the same name contains:
// Country-specific policy file for countries with no limits on crypto strength.
grant {
// There is no restriction to any algorithms.
permission javax.crypto.CryptoAllPermission;
};
which explains the differences. The standard, exportable JDK supports
key lengths up to 128 bits for encryption systems, except for RSA, which
is unlimited, and DES/Triple-DES, which have their own specific twists.
Note that this is only for encryption, _not_ signature, integrity check
or key agreement. In particular, Diffie-Hellman is unlimited in length,
as far as both cryptographic laws and policy files are concerned. The
limitation of Sun's JCE provider with regards to Diffie-Hellman is
internal to the code, and not an application of a law-constrained
policy.
--Thomas Pornin
Lew
>> Point being that they have to comply with the law. This is explained in the
>> README.txt file that comes with the stronger policy files.
Roedy Green wrote:
> Anyone got a link to the official story?
I'm reasonably certain that the README.txt that I cited is the official story.
It comes with the unlimited-strength policy files from the java.sun.com
download page.
<http://java.sun.com/javase/downloads/index.jsp>
The download is under 9 KiB, as small as some online PDFs.
They're the ones who talk about compliance with the law. From the wording, I
don't think they're speaking specifically of U.S. law. Were you?
--
Lew
Christian
> On Thu, 16 Jul 2009 20:35:16 +0200, Christian <fake...@xyz.de> wrote,
> quoted or indirectly quoted someone who said :
>
>> hmm problem seems to be still there...
>> just no longer appearing that often.. and only when being Client and not
>> Server
>
> Is there some sort of protocol-sniffing tool that lets you sort out
> problems like this for SSL? Or is that a self-contradictory request?
I think there are possibilities if you have the private key to sniff an
SSL/TLS connection with wireshark.
Though I never did this. Also I don't think its possible with DHE key
exchange.. as the DHE private key part is somewhere hidden in your java
heap.. and not in your keystore file.
Though currently I am only using loggers to detect what my connections
are doing.. to check what protocol/cyphersuite is choosen .. and what
errors appear..
which is quite restricting... when you get an error that tells you that
your key is either too small or too large... or that a bad prime size
has been provided.. now which is it?
Roedy Green
quoted or indirectly quoted someone who said :
>
>They're the ones who talk about compliance with the law. From the wording, I
>don't think they're speaking specifically of U.S. law. Were you?
I am not great with legalese, but it sounds like the problem is with
IMPORT not US export now. A law against making it difficult for a
government to snoop on its citizens at least makes sense, even if it
is odious.
--
Roedy Green Canadian Mind Products
http://mindprod.com
"The industrial civilisation is based on the consumption of energy resources that are inherently limited in quantity, and that are about to become scarce. When they do, competition for what remains will trigger dramatic economic and geopolitical events; in the end, it may be impossible for even a single nation to sustain industrialism as we have know it in the twentieth century."
~ Richard Heinberg, The Party�s Over: Oil, War, and the Fate of Industrial Societies
Lew
Java distribution]
Roedy Green wrote:
> I am not great with legalese, but it sounds like the problem is with
> IMPORT not US export now. A law against making it difficult for a
> government to snoop on its citizens at least makes sense, even if it
> is odious.
You are absolutely correct on all points, particularly on the odiousness.
I wonder if Sun knows that there are real legal problems out there or are just
in the habit of covering their butt and afraid to stop.
--
Lew