* Christian Uebber:
> TLS over TCP could attach session information to created sockets in a
> 1:1 relationship.
There's a separate class for non-TCP (but TCP-like) TLS called
SSLEngine. Perhaps you can expose a similar class for DTLS? This way,
your implementation would not be tied to UDP.
* Max Wang:
> I'm sending a byte[100] on client side using 100 calls of
> write(int). When receiving them on the server side using
> read(byte[100]), I need to call it 100 times and each time it only
> returns 1.
>
> Does this mean the client generates one SSL packet for each write()
> call?
So
lf-signed? Wouldn't
it break the chain in that case?
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
y to deal with this type of resource
exhaustation. To deal with corrupted files, it is sufficient to grow
arrays as the file is read, so you will hit the end of the file before
the OOM error occurs.
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegss
On 04/01/2013 08:26 PM, Valerie (Yu-Ching) Peng wrote:
Yes, please find the correct webrev at:
http://cr.openjdk.java.net/~valeriep/7155720/webrev.00/
I think in the second hunk of the patch, you should call dlclose().
--
Florian Weimer / Red Hat Product Security Team
again, which is
subject to blocking.
--
Florian Weimer / Red Hat Product Security Team
of OpenJDK 7 in that Fedora version.
However, I noticed that /dev/{u,}random is opened three times each (and
the file descriptors are kept open).
--
Florian Weimer / Red Hat Product Security Team
or this initialization would help
to avoid blocking on startup.
--
Florian Weimer / Red Hat Product Security Team
API of the native library changes, but the Java code still relies on
old API. The fix is to load versioned shared libraries instead.
Hmm. Why doesn't the "j2pcsc" library link against the right version of
libpcsclite.so?
--
Florian Weimer / Red Hat Product Security Team
switch to libpcscspy instead. But the latter is part of
the development package only, and I don't know how useful it is for
production use.
(All this is about GNU/Linux. Windows is clearly different, not sure
about the other POSIX platforms.)
--
Florian Weimer / Red Hat Product Security Team
variant which take a PrivilegedExceptionAction
argument to avoid this?
--
Florian Weimer / Red Hat Product Security Team
versed the order of the free() operations.
The change looks okay to me. However, this addresses not a memory leak,
but a user-after-free bug. (It might materialize as a leak if you have
a malloc implementation that overwrites objects with zeros when they are
freed, but that seems unlikely.)
xample, on some systems, "to" and
"to." return different address records, and for some applications, the
difference is rather important.
(This applies only to non-Windows systems, Windows has its own
idiosyncrasies when it comes to the trailing dot.)
--
Florian Weimer / Red Hat Product Security Team
because that's the party that picks the cipher suite.
I wonder if an enum (with members LOCAL and PEER, and perhaps
UNSPECIFIED) would be more appropriate than a boolean flag.
--
Florian Weimer / Red Hat Product Security Team
ion? This looks like useful information
to me.
--
Florian Weimer / Red Hat Product Security Team
match. That not only looks worse, but it's potentially harder to
debug as well.
I still think it's better to remove the dlopen/dlsym machinery and use
dynamic linking instead.
--
Florian Weimer / Red Hat Product Security Team
the status array
is too short.
The logic in Java_sun_security_smartcardio_PCSC_SCardGetStatusChange
appears to be correct, but I wonder if it would be clearer to use calloc
for allocation and avoid the interlocked i/j/k loop counters, at the
cost of calling free on a few NULL pointers.
a warning that this happens to the
CipherInputStream documentation seems prudent.
--
Florian Weimer / Red Hat Product Security Team
xists on
Linux (and people argue that it's against the RFC). The BSD sockets API
cannot properly report ICMP errors even if the network generates.
Is this really required for DTLS?
--
Florian Weimer / Red Hat Product Security Team
u can still use LD_LIBRARY_PATH or LD_PRELOAD. But isn't
there an expectation that PCSC will provide a dispatching layer of its own?
--
Florian Weimer / Red Hat Product Security Team
d be outdated by now).
--
Florian Weimer / Red Hat Product Security Team
haven't got it anymore, but I believe I used a trust manager
that returned a subclass of X509CertImpl with an overridden getEncoded()
method that simply returned crafted DER. No further changes or
bootclasspath hacks were required.
--
Florian Weimer / Red Hat Product Security Team
On 03/27/2014 02:34 PM, Florian Weimer wrote:
IIRC, I sent you a reproducer when reporting CVE-2009-3876 that does
this. I haven't got it anymore, but I believe I used a trust manager
Sorry, this has to be an X509KeyManager with a suitable
getCertificateChain() method.
that retur
actually prefers this mechanism.
Hotspot is supposed to optimize this scenario eventually, eliding the
allocation and inlining the code, as long as you use a lambda. Maybe we
won't get there during OpenJDK 9, but optimizing this by hand looks a
lot like defeat to me.
--
Florian Weimer / Re
On 03/24/2014 05:30 PM, Florian Weimer wrote:
This CR adds a new class java.security.StandardMessageDigests:
<http://fweimer.fedorapeople.org/openjdk/standard-message-digests/>
Could I get a bug number if this change is fine in principle?
Cryptographic hash functions are frequentl
supported, we could drop
the checked exception, making it easier to initialize objects. This
would be an added benefit, then.
--
Florian Weimer / Red Hat Product Security Team
mplest possible case
where the instantiation overhead is most visible.
--
Florian Weimer / Red Hat Product Security Team
y and
still need shifting and masking.
Maybe it's better to store the components as ints, or remove the fields
completely and use accessors that extract the components from the
version field as needed?
--
Florian Weimer / Red Hat Product Security Team
t length) {
MessageDigest md = threadLocalMDs.sha1();
md.update(buffer, offset, length);
return md.digest();
}
The actual digest object would not be exposed through this interface.
This would cover the use case of hashing short buffers, where the
instantiation overhead is
you think providing more efficient means for hashing
relatively short byte sequences isn't worth the effort?
--
Florian Weimer / Red Hat Product Security Team
isons.
I was just wondering if accessor methods (or storing the values as ints)
would make it less likely that the issue reoccurs in a different
variant. But the new checkRecordVersion() probably covers that.
--
Florian Weimer / Red Hat Product Security Team
directly supply the OCSP response to be stapled, perhaps as part of the
extended trust manager.
--
Florian Weimer / Red Hat Product Security Team
On 05/06/2014 03:37 PM, Xuelei Fan wrote:
On 5/6/2014 9:31 PM, Florian Weimer wrote:
On 05/06/2014 02:00 PM, Xuelei Fan wrote:
Storing both int version and major/minor byte versions is a little bit
redundancy. The update is significant. I will focus on the signed byte
issue in this fix
On 05/06/2014 04:05 PM, Xuelei Fan wrote:
On 5/6/2014 9:36 PM, Florian Weimer wrote:
On 04/02/2014 01:19 AM, Xuelei Fan wrote:
Here is the updated version:
http://cr.openjdk.java.net/~xuelei/8034248/jep-csre-v01.txt
Updated the description section and a few words so that it is easier to
E for general use, we
may need to evaluation too much uncertainties or limitations.
Okay, let's bury this for now. We can revisit it again once
hardware-accelerated hashing makes the instantiation overhead more
visible. :-)
--
Florian Weimer / Red Hat Product Security Team
On 05/15/2014 04:09 AM, Xuelei Fan wrote:
The actual problem is, what if I want to use 121 seconds? It is a
possible timeout value in practice.
I assume you could specify it as 121000 milliseconds. :-)
--
Florian Weimer / Red Hat Product Security Team
ncode
backslashes, which would be needed to cover the entire range of valid
domain names.
--
Florian Weimer / Red Hat Product Security
On 07/28/2014 10:57 AM, FELIX YANG wrote:
JDK Issue: https://bugs.openjdk.java.net/browse/JDK-8043836
This bug does not seem to be publicly accessible.
--
Florian Weimer / Red Hat Product Security
I noticed that the implementation of DigestInputStream does not feed
skipped-over bytes to the message digest. The specification is silent
on this, and I'm not sure if this a specification deficiency or an
implementation bug.
--
Florian Weimer / Red Hat Product Security
5280 is *not* to allow "_" in dNSName.
However, other PKIX implementations (OpenSSL, NSS) do not seem to verify
dNSName syntax at all, so it might be necessary to drop the check for
interoperability reasons in OpenJDK, even if it makes OpenJDK less
compliant with RFC 5280.
--
Flor
952, which is referenced in
RFC 1123) does not permit underscores.
--
Florian Weimer / Red Hat Product Security
9-dev code. The name "www.3com.com" is only present in
the SAN.
--
Florian Weimer / Red Hat Product Security
nice because it has a link to errata and updating RFCs.
--
Florian Weimer / Red Hat Product Security
On 08/07/2014 03:32 PM, Sean Mullan wrote:
On 08/07/2014 08:47 AM, Florian Weimer wrote:
I wonder why using the HTTPS to access <https://www.3com.com> works with
the current jdk9-dev code. The name "www.3com.com" is only present in
the SAN.
Is the SAN extension non-criti
ause of the high
allocation rate of the old code.
The performance improvement on 32-bit architectures is probably a bit
less, but I suspect that using four ints instead of two longs would
penalize 64-bit architectures.
--
Florian Weimer / Red Hat Product Security
a fix:
<http://mail.openjdk.java.net/pipermail/security-dev/2014-August/011009.html>
The AES-GCM implementation still conses a lot in unrelated parts of the
code, but that's a separate fix.
--
Florian Weimer / Red Hat Product Security
nsics for the finite field
multiplication?
I'd like to work on a follow-up patch to reduce memory allocation during
AES-GCM TLS transfers. Even after my GHASH changes, it seems we
allocate four bytes for every byte received, which should be easy enough
to avoid.
--
Florian Weimer / Red H
what you actually benchmarked? Just GHASH, or the full
cipher suite?
The actual impact of this change will be less than expected for TLS
because after fixing GHASH (for which I had already posted a patch), the
TLS implementation is largely GC-bound.
--
Florian Weimer / Red Hat Product Security
l an ongoing discussion in IETF TLS WG whether this is a
good idea. I think it is not, others disagree. I wanted to post this
CR nevertheless to avoid duplicating work.
--
Florian Weimer / Red Hat Product Security
I noticed a typo in CipherTestUtils, fixed like this:
<https://fweimer.fedorapeople.org/openjdk/tls-test-typo-fix/>
Could I please receive a bug ID for this, and maybe someone could review
and commit this patch? Thanks.
--
Florian Weimer / Red Hat Product Security
t work for everyone.
--
Florian Weimer / Red Hat Product Security
t JDK 9 (only path
changes), and the test still passes for me.
Could you share more details about your environment?
--
Florian Weimer / Red Hat Product Security
On 08/18/2014 02:32 PM, Florian Weimer wrote:
This change addresses a severe performance regression, first introduced
in JDK 8, triggered by the negotiation of a GCM cipher suite in the TLS
implementation. This regression is a result of the poor performance of
the implementation of the GHASH
s, they are going to help quite a bit as well. The other thing we
need to fix for TLS is that AES-GCM is a garbage collector stress test.
Last time I looked, for each transferred byte, there were four bytes
allocated on the heap.
--
Florian Weimer / Red Hat Product Security
On 01/15/2015 05:24 PM, Anthony Scarpino wrote:
>> Anthony, could you file a bug so that I can include its number? Thanks.
>>
>
> Here it is: https://bugs.openjdk.java.net/browse/JDK-8069072
Thanks. Updated webrev:
<http://cr.openjdk.java.net/~fweimer/8069072/web
On 01/16/2015 09:18 AM, Anthony Scarpino wrote:
>> On Jan 15, 2015, at 12:26 PM, Florian Weimer wrote:
>>
>> Yes, they are going to help quite a bit as well. The other thing we need to
>> fix for TLS is that AES-GCM is a garbage collector stress test. Last tim
K_SCSV is a bit of a wart, but it seems necessary for feature
parity with other TLS server implementations.
--
Florian Weimer / Red Hat Product Security
leases (In general, no APIs changes are allowed in JDK update releases).
I plan to backport only the server part, the client part is mostly there
for testing purposes.
--
Florian Weimer / Red Hat Product Security
Welch Two Sample t-test
data: old and new
t = 1.9356, df = 16.015, p-value = 0.07077
alternative hypothesis: true difference in means is not equal to 0
95 percent confidence interval:
-0.05278151 1.16258151
sample estimates:
mean of x mean of y
50.0819 49.5270
--
Florian Weimer / Red Hat Product Security
On 02/03/2015 03:18 PM, Xuelei Fan wrote:
> On 1/29/2015 5:59 PM, Florian Weimer wrote:
>> On 01/29/2015 04:39 AM, Xuelei Fan wrote:
>>> Hi Florian,
>>>
>>> Thanks for contribute this patch to OpenJDK.
>>>
>>> The draft of TLS_FALLBACK_SCSV i
urity-dev/2014-November/011458.html>
The latest webrev is here. Compared to the original submission,
copyright lines were updated, and the bug number was added:
<http://cr.openjdk.java.net/~fweimer/8069072/webrev.03/>
--
Florian Weimer / Red Hat Product Security
, I think it's too late to fix this bug now. That's why I just
added the identity counter. If you want the behavioral change instead,
I can implement that as well.
> Can you add a noreg-perf label to the bug?
Done, perhaps prematurely.
--
Florian Weimer / Red Hat Product Security
formance.)
The comment on processBlock(byte[], int, int) is confusing. I don't
understand what it is trying to say.
--
Florian Weimer / Red Hat Product Security
the number bytes per invocation to 16000, so perhaps this
isn't issue for the current application.
--
Florian Weimer / Red Hat Product Security
by
pyasn1 and verified using Peter Gutmann's dumpasn1.
I couldn't find any other tests for PolicyQualifierInfo, but you may
have closed tests that need adjusting.
--
Florian Weimer / Red Hat Product Security
On 02/17/2015 08:59 PM, Anthony Scarpino wrote:
> On 02/17/2015 12:57 AM, Florian Weimer wrote:
>> On 02/16/2015 10:11 PM, Anthony Scarpino wrote:
>>> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/
>>
>> I think the “state” field in GHASH should be final.
On 02/17/2015 09:03 PM, Anthony Scarpino wrote:
> On 02/17/2015 02:59 AM, Florian Weimer wrote:
>> On 02/16/2015 10:11 PM, Anthony Scarpino wrote:
>>> Hi,
>>>
>>> I'm requesting a code review to intrinsify the GHASH operations for both
>>>
t->field.
>
> But in blockMult() you access them outside main loops. As result the
> code without intrinsic should not be affected much.
Making the state field final is still a good idea, I think.
--
Florian Weimer / Red Hat Product Security
On 02/20/2015 11:23 PM, Sean Mullan wrote:
> On 02/17/2015 09:30 AM, Florian Weimer wrote:
>> On 02/16/2015 11:13 PM, Sean Mullan wrote:
>>
>>>> Based on that, PolicyQualifierInfo should have implemented value-based
>>>> equals() and hashCode(), and the ident
64 alphabet. PEM is more restricted
> and as I know openssl rejects PEM with illegal chars (Ex, "!" as in bug
> report and test). This fix will also reject them.
Shouldn't you add a Base64.getPemDecoder() with these semantics? I
think this decoder would be useful in other co
oblem before because the hash was identity-based), and the cost of
computing hash codes even for single-element sets.
--
Florian Weimer / Red Hat Product Security
parate APIs,
this is less likely because for this to happen, applications would have
to actually support this as a configuration option, which hopefully will
not pass code review.
For the backport to JDK8, I propose to backport the server-side change
only, so there will be no API impact.
--
Flo
able. I have add an @implNote mentioning that the default
provider sends TLS_FALLBACK_SCSV.
<http://cr.openjdk.java.net/~fweimer/8061798/webrev.01/>
There are now additional tests which explicitly verify the cipher suite
list sent by the client.
--
Florian Weimer / Red Hat Product Security
On 05/07/2015 01:39 AM, Xuelei Fan wrote:
> On 5/6/2015 9:42 PM, Florian Weimer wrote:
>> On 05/06/2015 01:42 AM, Xuelei Fan wrote:
>>> As additional APIs are strongly desired, what do you think to make the
>>> API more general and easy to use?
thought these
standard. The slightly awkward name is due to the fact that it's just a
flag send to the server, and it does not cause the TLS implementation to
perform the fallback on its own. What about this?
public void setProtocolFallbackInProgress(boolean inProgress) {…}
public boolean isProtocolFallbackInProgress() {…}
--
Florian Weimer / Red Hat Product Security
receives an inappropriate_fallback alert with
my TLS_FALLBACK_SCSV patch, but I can't see a reason why the behavior
for other alerts would be different.
--
Florian Weimer / Red Hat Product Security
diff --git a/src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java b/src/java.base/
On 06/16/2015 05:49 AM, Xuelei Fan wrote:
> On 6/15/2015 5:58 PM, Florian Weimer wrote:
>> On 06/03/2015 03:56 AM, Xuelei Fan wrote:
>>
>>> I can sponsor you for the specification update approval and changeset
>>> integration if needed.
>>
>> I
l, and perhaps
developers will use java.util.Random instead.
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
* Sean Mullan:
> On 12/15/10 10:38 AM, Florian Weimer wrote:
>> * Sean Mullan:
>>
>>> Please review the following list:
>>> http://cr.openjdk.java.net/~mullan/5001004/review.00/StandardNames.html#impl
>>
>> "SHA-1" or "SHA1"? (Our
ching from
MessageDigest.getInstance(String) to cloning a prototype object,
presumably due to the elaborate way the actual implementation class is
discovered.
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
ficate cert =
(X509Certificate)cf.generateCertificate(inStream);
* } finally {
- * if (inStream != null) {
- * inStream.close();
- * }
+ * inStream.close();
* }
*
*
There are also instances in actual code (in
javax/crypto/JceSecurity.java, for instance), but changing them
ava
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/test/sun/security/pkcs12/Bug6415637.java Fri Jun 17 15:05:06 2011 +0200
@@ -0,0 +1,291 @@
+import java.io.ByteArrayInputStream;
+import java.math.BigInteger;
+import java.security.KeyStore;
+import java.security.cert.X509Certificate;
+import java.security.interf
across calls because you do not completely control which implementing
methods you call.
Do you plan to restructure the code to address the related bug 6974037?
I believe the MAC check should come first, as a matter of cryptographic
hygiene.
--
Florian Weimer
BFK edv-consulting G
it wouldn't if it's not
self-signed.
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
Java API) seems a bit superfluous, IMHO. But perhaps I misunderstood
what you meant.
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
* Florian Weimer:
> Presumably, this does not count as a small change, so BFK needs to sign
> a contributor agreement. Is the sun.com email address still the right
> one to submit the scanned copy?
We got the paperwork sorted out, so we can start work on the process of
getting the
* Weijun Wang:
> I think security changeset should go to tl forest first.
Is this <http://hg.openjdk.java.net/jdk8/tl>?
This forest rejects OpenJDK 6 as a bootstrap compiler. Do I need a
working build of OpenJDK 7 first?
--
Florian Weimer
BFK edv-consulting GmbH
date.
I see that the test was dropped in the final webrev and the commit
(cfc05963734e). Was this intentional? The Makefile changes are still
present, though.
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
* Seán Coffey:
> Should this test be set to run manually ?
>
> 5 mins is far too long for a jtreg unit test IMO.
If the visibility of the internal helper method is changed, you could
test with a custom InputStream and ByteArrayOutputStream, which would
cut down memory requirements.
--
ch is compliant with the specification.
Because of the division of zero issue, the second change does not
actually modify visible behavior.
To my knowledge, there is now an OCA which covers this change.
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
K
The attached patch fixes a few warnings in javax.net.ssl.*. All the
overrides appear to be intentional.
--
Florian Weimer / Red Hat Product Security Team
# HG changeset patch
# User Florian Weimer
# Date 1353076204 -3600
# Node ID 1978e4b72308472c5b70f31d2bf2b927b73e08a0
# Parent
asn't sure what to use. Let's use the attached version instead.
Please let me know if you want a sponsor to push the patch.
Yes, I would appreciate that.
--
Florian Weimer / Red Hat Product Security Team
# HG changeset patch
# User Florian Weimer
# Date 1
ed by Red Hat. If necessary, I can initiate the process.
--
Florian Weimer / Red Hat Product Security Team
Is the extension actually being processed?
sun.security.ssl.HandshakeHash.setCertificateVerifyAlg(String) appears
to have no effect because the cvAlg member is never read.
--
Florian Weimer / Red Hat Product Security Team
This patch removes unused variables. If any of them have to stay
because they are accessed through reflection (possibly by legacy code),
there really ought to be a comment reflecting that.
The last hunk removes a NullPointerException, I think.
--
Florian Weimer / Red Hat Product Security
sequence number and ensures that attempts to
* delete or reorder messages can be detected.
Quotes from the RFC should probable marked as such.
--
Florian Weimer / Red Hat Product Security Team
On 11/23/2012 12:54 PM, Xuelei Fan wrote:
On 11/23/2012 7:22 PM, Florian Weimer wrote:
On 11/22/2012 04:00 PM, Xuelei Fan wrote:
Hi Valerie, Max or Brad,
Can you review the update for JDK-7030966? It is the JSSE part of JEP
115.
webrev: http://cr.openjdk.java.net./~xuelei/7030966/webrev.00
On 11/23/2012 01:52 PM, Xuelei Fan wrote:
Great catches! Looks fine to me.
Please let me know if you want a sponsor to push the patch.
Yes, please.
--
Florian Weimer / Red Hat Product Security Team
On 11/23/2012 02:58 PM, Xuelei Fan wrote:
On 11/23/2012 1:59 AM, Florian Weimer wrote:
Is the extension actually being processed?
Yes.
sun.security.ssl.HandshakeHash.setCertificateVerifyAlg(String) appears
to have no effect because the cvAlg member is never read.
Need to clean up the code
This patch removes unused constructs related to the TLS 1.2
signature_algorithm extension. See the brief discussion here:
<http://mail.openjdk.java.net/pipermail/security-dev/2012-November/006037.html>
(I need a sponsor for this patch.)
--
Florian Weimer / Red Hat Product Security Tea
1 - 100 of 116 matches
Mail list logo
