Hello Alan,
Thank you.
Regards,
Alexander
On 10.04.2015 19:01, Alan Bateman wrote:
On 10/04/2015 16:50, alexander stepanov wrote:
Hello,
Could you please review the following fix
http://cr.openjdk.java.net/~avstepan/8077332/
for
https://bugs.openjdk.java.net/browse/JDK-8077332
Some HTML cl
Thanks!
On 10.04.2015 20:07, Sean Mullan wrote:
On 04/10/2015 12:01 PM, Alan Bateman wrote:
On 10/04/2015 16:50, alexander stepanov wrote:
Hello,
Could you please review the following fix
http://cr.openjdk.java.net/~avstepan/8077332/
for
https://bugs.openjdk.java.net/browse/JDK-8077332
Some
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
On 10.04.2015 00:36, [email protected] wrote:
> New JEP Candidate: http://openjdk.java.net/jeps/244
>
> - Mark
Hi,
would it not be an great idea to combine all these new extensions to an
generic way how to handle the SSL Protocol Handshake ?
JEPS-244 ALPN
http://openjdk.java.net/jeps/8046
On 04/13/2015 09:58 AM, Thomas Lußnig wrote:
On 10.04.2015 00:36, [email protected] wrote:
New JEP Candidate: http://openjdk.java.net/jeps/244
- Mark
Hi,
would it not be an great idea to combine all these new extensions to an
generic way how to handle the SSL Protocol Handshake ?
Do
Hi,
On Mon, Apr 13, 2015 at 6:22 PM, David M. Lloyd wrote:
> Do you know of a Java TLS implementation that has APIs like this already? I
> am also interested in this for the ability to implement authentication
> mechanisms (GSSAPI and SASL) that rely on channel binding, so I would like
> to see
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
On Apr 13, 2015, at 4:51 AM, Zoltán Majó wrote:
>
> please review the following patch.
Good. This line has a typo ("encrypBlock" = gang member induction party foul?):
+ * AESCrypt.encrypBlock method can be intrinsified on the HotSpot VM
— John
On 04/10/2015 07:18 PM, Jason Uh wrote:
Revised webrev: http://cr.openjdk.java.net/~juh/8076117/01/
Hi Jason,
Just a few comments:
* Validator
272: I would name this flag checkUnresolvedCritExts, since we only care
about them if they are critical and unresolved.
273: You should only ignor
Hi,
Could you forward the whole message, with the patch, to the security list. I
have only received John's response, but not the webrev.
Thanks
Tony
> On Apr 13, 2015, at 12:50 PM, John Rose wrote:
>
>> On Apr 13, 2015, at 4:51 AM, Zoltán Majó wrote:
>>
>> please review the following
Hi Tony,
> On 13 Apr 2015, at 22:09, Anthony Scarpino
> wrote:
>
> Hi,
>
> Could you forward the whole message, with the patch, to the security list. I
> have only received John's response, but not the webrev.
please find the original RFR below. I’ve sent it to
[email protected]
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
On 10.04.2015 00:36, [email protected] wrote:
> New JEP Candidate: http://openjdk.java.net/jeps/244
>
> - Mark
Hi,
would it not be an great idea to combine all these new extensions to an
generic way how to handle the SSL Protocol Handshake ?
JEPS-244 ALPN
http://openjdk.java.net/jeps/80463
Hi,
please review the following patch.
Bug: https://bugs.openjdk.java.net/browse/JDK-8067648
Problem: On architectures with hardware support for AES operations, the
Java version (the version in the JDK sources) of the
com.sun.crypto.provides.AESCrypt::encryptBlock(byte[], int, byte[], int)
Thanks, Sean.
Here is a revision:
http://cr.openjdk.java.net/~juh/8076117/02/
On 04/13/2015 12:59 PM, Sean Mullan wrote:
On 04/10/2015 07:18 PM, Jason Uh wrote:
Revised webrev: http://cr.openjdk.java.net/~juh/8076117/01/
Hi Jason,
Just a few comments:
* Validator
272: I would name this fl
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 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 che
Hi Thomas,
I am not actually turning off the check for unknown critical extensions.
When validating with TYPE_PKIX, CertPathValidator will already have
verified all extensions (and an exception would already have been thrown
for any violations). This fix is merely to take out what would be a
Thanks for the proposal.
A general TLS/DTLS extension API and pluginable extension implementation
is a good idea. But as there is no rules about how an extension may
impact the handshake flow, it is not easy to define a general APIs for
all existing known or unknown extensions and future extensio
Hello,
RFC 7465 [1] has been published to prohibit RC4.
Please review this fix which disables RC4 cipher suites in JDK 9 by
adding "RC4" to "jdk.tls.disabledAlgorithms" security property.
Webrev: http://cr.openjdk.java.net/~asmotrak/8076221/webrev.00/
Bug: https://bugs.openjdk.java.net/browse
20 matches
Mail list logo
