I'd searched for some time now, also asked the bc-maillist, but I still didn't made any progress.
What's the main problem: As widely known, when using an Oracle jvm one is restricted to limited security by Oracles security policy to only use AES128.
So I thought using BouncyCastle as security provider would get me around this issue. And sadly it's not as easy as it might sound or as I thought. When using bc as jca/jce/jsse provider it's somehow still limited by Oracles policy. That's not what I thought an external lib is and should be used for, as my understanding of an additional external lib is to add functionality java itself or the used jvm isn't able to do by itself.
I've got this awnser from one of the bc devs:
BC doesn't check jre-policy; it's enforced by the JRE, as the name would
suggest. BCJSSE is affected because it uses crypto via the JCE.
BCJSSE is built over a low-level TLS library that (when used standalone)
can be configured to use non-JCE crypto, and thus is outside the policy
So I've a simple question: How do I set up a TLS-connection with bc so I'm able to use AES256 suites?
You can "crack" your way around any security restrictions by "simple" use of reflections:
[code removed - if someone wants to know please contact me privately]
Simple there're some lines of code to override some specific fields and clear out others and replace them with some other values - with a little help of some reflection magic.
Sure - one can use this trick - but using it also changes Sun/Oracle provider - so no BC needed at all - but that's not what I want and neither is it what I think how "additional libraries" should work. Yea - BC jce/jca/jsse still uses some of the "standard" classes - and maybe the restriction is somehow implemented in it so a lib just can't change this behaviour simply by just how Cipher is implemented - but there is no clear awnser to this.
BUT: As the reply I quoted suggests: It seems to be somehow possible to init BCJSSE in some specific way this limitation is somehow ignored or overridden - but sadly I didn't got any response about how to do this from the quoted bc-dev.
As about laws (that's why I removed the code before posting): I don't know much about them - but for me as a citizen of Germany the laws of the european union applies to me - and they grant me rights to use not only such strong but even stronger crypto - and to also freely speak about it.
I did posted my "magic code" on a german forum wich I know the server is located in Germany - so I know I'm freely allowed to upload such code to it and speak about it. But I don't know about the ranch servers - and about the import-laws of the country it's located in. Also I guess it would be against some end-user-licence-"stuff" (I wanted to make some "fun" here - but decided not to) of some sort.
So that's why I'm looking for a lib I can simply plug in and use w/o any "hacky"-stuff (wich can be somehow restricted by other issues) but also be able to use "default" java classes so I don't have to use re-implemented ones - wich, at least to some insecure stage, I could to by myself.
I've read about "jessie" http://jessie.nongnu.org/ wich claims the same as BC:
Jessie is a free, clean-room implementation of the Java Secure Sockets Extension, the JSSE. It provides the core API for programming network sockets with the Secure Socket Layer (SSL), ...
blah blah blah - ok, I'll give it a try - I'll report back when I got some news ...
jessie - uhm, nevermind - simple: outdated, only support TLSv1.0
about BC: took me some time but got it working in the end - only to find out BC only supports following TLS-cipher-suites:
only AES128? - ok - so it's basicly down to what oracle w/o unlimited policy provides
before anyone asks: yes - this was also tested on a opensuse openjdk wich by default has no limits - also tested on windows with unlimited "crack" - BC simple doesn't support any better
so - implement a jsse-provider myself to support ciphers I've set up my server to? nah - to risky from security point of view
well - I guess there's simple no way to get what I want to work - cruel world
about what's my problem: it's not about me using strong crypto - it's about to make code I distribute use it
so when I publish my application I can't ask the end-user to fiddle around with policy files - or rely on vendor-specific hack-code to crack limits at runtime - it simply has to work - therefore I need a simple drop-in replacement to get it to work out-of-the-box
even simple update of code from webserver (wich is set to specific cipher suites:
TLS_RSA_WITH_AES256_GCM_SHA384) isn't possible but have to rely on non-TLS HTTP
so - to close this of: what I want can't be done with BC - and sadly it doesn't seem like any other JSSE/JCE/JCA provider implementations out there to try - so I've to stick with limits made at times of cold war wich nowdays the reason for all-day security issues and hacks just because the "laws of some state of the us" are forced to apply to the rest of the world - and therefore it's impossible to spread secure software around
and if you do you risk law suites - kthxbai - when seen this way we simple could drop this whole security-crypto-stuff and just use plaintext all over - wouldn't made any difference - but wouldn't waste energy by someone try to crack it
This is org.bouncycastle.tls.DefaultTlsServer
This is org.bouncycastle.tls.DefaultTlsClient:
So, to use AES256 with SHA384 you have to override this list - and as its stuck in constructor you have to build your own sub-class:
Also: very important - you have to use an instance of BcTlsCrypto - otherwise when using JcaTlsCrypto the built-in javax.crypto.Cipher is used - wich is then again limited - so no use for BC at all - you simple can'T mix 'em.
What's left: One still has to implement cerificate validation.
This is not how it's supposed to work. A plug-in replacement should handle all this by itself - no need for implementing abstract classes, learning from source cause doc is empty and you can'T hardly find any information - and what you can find is mostly outdated and can't be used anymore - very much thanks @thebclegion - NOT
Ok - as this is same "cracking" as my other code, here you go:
AES-128 is probably more than secure enough for your application. If you think it isn't, you need to come up with some really good reasons. By the time the use of AES-128 becomes discouraged, AES-256 will be widely available. In fact, Java 9 will be released with the unlimited policy enabled by default.
I strongly advise you to stop going down this pointless route. If your clients care that much about the unnecessary level of strength, they should care enough about installing a couple of policy files in their JRE.