Hi,
is there anyone working on OCSP-Stapling ?
I patched my java version to get it running for server side.
Maybe i can help with some parts of the implementation.
Gruß Thomas
Hi,
even if i am new in this list i looked at the solution and have an question.
Why there is an switch to turn off check for unknown critical extensions ?
>From my point of view as an developer i would say an more secure solution
would be instead of an boolean switch, make an Set checkedOids as
n
h such an extension options it would be much more simple do implement
new Extensions.
Gruß Thomas Lußnig
Hi,
this could be an interface for such an Callback.
It allow hello extensions as well as handshake extensions.
If it would be really clean we would have an handler for:
- NPN
- ALPN
- Channel ID
- ZertificateSignature
- OCSP-Stapling
- ServerName
- Session Ticket
The handler could be also used f
Hi,
i checked the CipherSuites in JDK and found that in the JDK there is and
mistake i think.
In CipherSuite the method add set the PRF to NONE only if obsoleted less
than TLSv1.2.
But if the suite is forbidden / obsoleted in TLSv1.2 the check must be
<= (less or equal)
if i am correct.
http://gr
Hi,
even if i am new in this list i looked at the solution and have an question.
Why there is an switch to turn off check for unknown critical extensions ?
>From my point of view as an developer i would say an more secure solution
would be instead of an boolean switch, make an Set checkedOids as
n
h such an extension options it would be much more simple do implement
new Extensions.
Gruß Thomas Lußnig
s for extension parameters any more.
>
> JSSE is open source and an provider based framework. Alternatively,
> we'd like to accept extension implementation contributions, or developer
> can define their own private provider if necessary.
>
> Regards,
> Xuelei
>
> On 4
oes not set the PRF to the invalid NONE as i would expected with the
description.
Gruß Thomas
> On 4/14/2015 2:25 AM, Thomas Lußnig wrote:
>> Hi,
>>
>> i checked the CipherSuites in JDK and found that in the JDK there is and
>> mistake i think.
>> In CipherSuite the
Hi,
i looked at the patch files looks OK for me too.
Since i also implemented it i can tel the server part ist ok.
Once think i found maybe an optimisation:
instead of
mesg.protocolVersion.compareTo(getActiveProtocols().max) < 0
maybe use
mesg.protocolVersion.v < getActiveProtocols().max.v
in
Hi,
1) There are two types of extensions:
a) That modify the directly how the engine works like
[max_fragment_length,heartbeat,encrypt_then_mac,extended_master_secret,SessionTicket,...]
b) That provide information (modify the network protocol) like
[npn,alpn,status_request,...]
2) Some of the exti
Hi,
most of it look ok for me, but in
"http://cr.openjdk.java.net/~vinnie/8062552/webrev.01/src/share/classes/sun/security/util/KeyStoreDelegator.java.patch";
i found in the
method engineLoad the exception handling an bit ugly.
+} catch (Exception e) {
+
+// in
Hi,
1) Would it not be an good idea to check the first bytes of the message
so that the dual class already know what type the stream is
and there is no unnecessary instanciation of exceptions and engine class?
2) If we add an "smart" keystore why we limit it to two types? I do not
see any reason w
backport/use it ?
Why build this limited version for one single usecase instead of using
the more gerneral solution ?
>
>> On 23 May 2015, at 09:42, Thomas Lußnig wrote:
>>
>> Hi,
>>
>> 1) Would it not be an good idea to check the first bytes of the message
>>
Hi,
two points that come directly to my mind when i checked the code:
1) An Error in the description.
+// If plast >= plen then restrictedPkg is longer than pkg by at
+// least one char. This means pkg cannot start with restrictedPkg,
+// since restrictedPkg w
Hi,
here are some comments about what i was thinking:
http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java.patch
- Why not make the parsed message available ?
If the client wan't to check it he need to parse/implement the
Hi,
we are talking about security. So is there any reason why the OpenJDK
should include not the same Blacklisted Certificates
as in other Jdk Versions? Or with other words does it make sense to do
other blacklist tests in openjdk at all ?
Gruß Thomas
On 18.06.2015 01:00, Rajan Halade wrote:
> M
On 21.06.2015 17:56, Jamil Nimeh wrote:
>
> The X509TrustManager, if configured to do revocation checking at all,
> should handle the checks so the client doesn't have to. Can you tell
> me a little more about what environment a customer would want to
> re-check the responses above and beyond what
in state close_wait?
- Maybe check if we can read one byte (nonBlocking) because we are not
expecting data on idle connection.
Gruß Thomas Lußnig
p.s. My workaround
public void run() {
do {
try { Thread.sleep(LIFETIME); } catch (final
InterruptedException e) {}
sy
Hi,
even if it looks complicated for you the idea is that your code is not
hard wired to MD5 or SHA1 but in ideal case
it is configured. Than you do not know in advance if the selected digest
is available.
On the other hand no one say that you can create your own helper/tools
class.
The idea i
the debug log.
If there is no bug opened yet i can provide an sample with client/server
that demonstrate the bug
and can maybe used for regression tests.
Gruß Thomas Lußnig
2018-12-10T12:16:41.666
javax.net.ssl|DEBUG|15|https://fqdn/path)|2018-12-10 12:16:41.666
CET|ClientHello.java:65
that the jdk as server does not check if
the received messages matches the selected protocol version.
-> I think this does not open an security issue but should be
verified too, it maybe wanted for compatibility but than it should be
configurable per connection.
Gruß Thomas Lußnig
pack
Hi,
maybe two points.
1) Older lotus notes server have the problem.
2) The problem can be solved if you disable TLSv1.3 or even TLSv1.2
3) Maybe it would be an good idea to build an set of client hello's with
different options.
Or even an generator. Than you send if and check the result si
send 65535 as EC group that was causing the trouble.
Am 13.02.2019 um 23:08:22 schrieb Amir Khassaia:
Hi Thomas,
Can you confirm its tied to new extensions to TLS 1.2 client hello and
whether you diagnosed which one was the problem in Lotus Notes case ?
On Thu, Feb 14, 2019 at 9:05 AM Thomas
, 8, 8, true );"
Then in createExplicitNonce the nonce should become zero size but is
fixed length for AEAD of 8 bytes.
Both was seen in JDK-1.8.0_60
Gruß Thomas Lußnig
ed as IETF RFC?
Looks like the proposal was not moving forward since May, 2014.
https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04
Thanks,
Xuelei
On 10/11/2015 3:59 PM, Thomas Lußnig wrote:
Hi,
when i extends "sun.security.ssl.CipherSuite" with
final static BulkCipher
Hi,
i checked the server with
https://dev.ssllabs.com/ssltest/analyze.html?d=nfe-homologacao.sefazrs.rs.gov.br
the result is more than bad. I think you should use SSL Context and
define what cipher/protocol you allow
and check the security.property that there is no restriction on key length.
Hi,
i think not only the cipher suite and protocol version. But many other
parts should be also
be public. Like Supported digest, curve types, etc...
And also these information should be available for the keymanger.
So that he is able to select certificate also based on the curve types.
Gruß T
Hi,
even if the case is with the current time not active. Is it an good idea
to define an fixed value
for random generator under special conditions that are time depending ?
Gruß Thomas
---
package sun.security.ssl;
RandomCookie(final SecureRandom sr) {
final long ts0 = System.c
Hi,
both errors have in common that there are about an change of allowed
hostnames.
But as for the second bug there is an big mistake. The underscore is
allowed for SRV and CNAME
but not for A records. For SRV records it is wide used in LDAP records
for MS Domain System (PDC).
But the Subject
Hi,
maybe you could tell more what you need to know about TLS 1.2 support?
Do you wan't an general overview of features (Stappling, SC, ...) or are you
are you interested in the available cipher suites. If you are so general
the simple
answer is that TLS 1.2 is supported as client and server on
Hi,
with JDK 8 it was Possible to extend the List of Available CipherSuites
by modify the sun.security.ssl.CipherSuite.
With JDK9 and the module system this is not any more possible with an
bootclasspath, is there any other way
to do it? Disable module check or something ?
Gruß Thomas
Hi,
is there any reason that the cipher and and the tls inclusion is split
into two separate jep?
And the second question is why is there no way for user to add new
cipher suites that can
be used in the tls protocol? Since i extend jdk8 with chacha for tls i
know that it would be
no big issue
Hi Jamil,
1) where there any guidelines about how the engineToString should be
formatted ?
I ask because i wondering why we need two new lines with access to the
System property.
If it is represented as single line json no need to line break would be
needed.
Gruß Thomas
/** * Creates a for
Hi,
this choice is even better than the current version. Because than the
default system wide
secure random provider is used.
Gruß Thomas
On 3/27/2018 12:23 AM, Jamil Nimeh wrote:
Another thought on #2: Another way we could go with this is to create
a new SecureRandom() or use JceSecurity.
Hi,
i found another point. The "key" field can be removed from ChaCha20Cipher.
1) This field is only set once and later checked if it was initialized.
But we do not want to knew is the key exists but if key bytes exists.
2) So if two lines are changed from key to keyBytes we can remove this
dless
of what the caller sets there?). Using IvParameterSpec with
ChaCha20-Poly1305 is more clear because it only allows the caller what
they need to get CC20/P1305 going, the nonce. Respectfully, I would
like to keep this as-is.
--Jamil
On 3/26/2018 12:45 PM, Thomas Lußnig wrote:
Hi,
same with key/keyBytes is with the class Poly1305 also here the key is
not used.
Gruß Thomas
On 4/11/2018 5:54 PM, Jamil Nimeh wrote:
Yes, that does appear to be the case, good catch! I'll make that change.
--Jamil
On 4/11/2018 7:18 AM, Thomas Lußnig wrote:
Hi,
i found an
example that
show the problem.*
*
Gruß Thomas Lußnig
*
*import*java.io.InputStream;
*import*java.io.OutputStream;
*import*java.net.InetSocketAddress;*
import*java.net.ServerSocket;*
import*java.net.Socket;*
import*java.net.URI;*
import*java.time.Duration;*
import*javax.net.ServerSocketFactory
Hi,
i got these NPE on my Server. With Java:
openjdk 11-ea 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11-ea+25)
OpenJDK 64-Bit Server VM 18.9 (build 11-ea+25, mixed mode)
java.lang.NullPointerException
at
java.base/sun.security.ssl.SupportedGroupsExtension$SupportedGroups.getEC
24.08.2018 00:00:41, Jamil Nimeh wrote:
Hi Thomas, can you reproduce the issue with debug logging turned on?
It may be helpful in conjunction with the stack trace you've
provided. You should be able to turn it on with -Djavax.net.debug=ssl
Thanks,
--Jamil
On 8/23/2018 2:41 PM, Thomas Lußnig
ange_modes extension".
If there is an PSK without an matching extension this should not kill
the connection i think. Nearly all other server accept this.
Gruß Thomas Lußnig
javax.net.ssl.SSLHandshakeException: pre_shared_key key extension is
offered without a psk_key_exchange_mode
Hi,
does the fix work if there is only one unknown named group ?
Not that the connection fails than with an better error text instead of
skiping the unknown group.
Gruß Thomas
On 12.09.2018 04:22:49, Xuelei Fan wrote:
Hi Jamil,
Would you please review the fix for the NPE issue:
http://cr
place is changed and the performance of parse is
improved wihtout change it.
Gruß Thomas Lußnig
On 10.08.2021 19:43:15, Сергей Цыпанов wrote:
On Tue, 10 Aug 2021 14:56:11 GMT, Claes Redestad wrote:
The code in `Integer.decode()` and `Long.decode()` might allocate two instances
of Integer/Long
44 matches
Mail list logo
