On 6/5/2018 10:37 PM, Weijun Wang wrote:
RandomCookie.java:
+ private boolean isT12Downgrade() {
+ return Arrays.equals(randomBytes, 24, 31, t12Protection, 0, 7);
+ }
+
+ private boolean isT11Downgrade() {
+ return Arrays.equals(randomBytes, 24, 31, t11Protection, 0, 7);
+ }
The "to" in Arrays::equals is exclusive, so please update 31 -> 32, 7 -> 8.
Good catch!
Also, at the end of
https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.1.3
RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH Implementations of
draft versions (see Section 4.2.1.1) of this specification SHOULD NOT
implement this mechanism on either client and server. A pre-RFC
client connecting to RFC servers, or vice versa, will appear to
downgrade to TLS 1.2. With the mechanism enabled, this will cause an
interoperability failure.
Has the current implementation implemented (and turned on) this mechanism?
Yes, the mechanism is turned on.
Thanks,
Xuelei
Thanks
Max
On Jun 5, 2018, at 12:12 PM, Xuelei Fan <xuelei....@oracle.com> wrote:
http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01
