This is a follow on to 28f33b4a which removes one of the boolean flags
and adds a test for the key-driven cipher selection.
Change-Id: If2a400de807eb19110352912a9f467491cc8986c
Reviewed-on: https://go-review.googlesource.com/8428
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Jacob Haven <jacob@cloudflare.com>
A CSR containing challengePassword or unstructuredName Attributes
(included in default OpenSSL prompts) would break ASN.1 parsing.
This updates the parsing structures to allow but then ignore these
fields.
See this CFSSL issue: https://github.com/cloudflare/cfssl/issues/115
Change-Id: I26a3bf1794589d27e6e763da88ae32276f0170c7
Reviewed-on: https://go-review.googlesource.com/8160
Reviewed-by: Adam Langley <agl@golang.org>
This change replaces all direct ECDSA/RSA sign and decrypt operations
with calls through the crypto.Signer and crypto.Decrypter interfaces.
This is a follow-up to https://go-review.googlesource.com/#/c/3900/
which added crypto.Decrypter and implemented it for RSA.
Change-Id: Ie0f3928448b285f329efcd3a93ca3fd5e3b3e42d
Reviewed-on: https://go-review.googlesource.com/7804
Reviewed-by: Adam Langley <agl@golang.org>
cl8167 introduced internal/syscall/windows.GetVersion, but we already
have that function in syscall.GetVersion. Use that instead.
Also revert all internal/syscall/windows cl8167 changes.
Change-Id: I512a5bf4b3b696e93aaf69e9e8b7df7022670ec0
Reviewed-on: https://go-review.googlesource.com/8302
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Reviewed-by: Minux Ma <minux@golang.org>
Windows XP SP2 and Windows 2003 do not support SHA2.
Change-Id: Ica5faed040e9ced8b79fe78d512586e0e8788b3f
Reviewed-on: https://go-review.googlesource.com/8167
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Commit 604fa4d5 made TLS 1.0 the default minimum version. This commit
amends a comment to reflect that.
This is where the default is used in the absence of an explicit version
being set:
edadffa2f3/src/crypto/tls/common.go (L391-L393)
Change-Id: I8f1117ecdddc85bb1cc76a6834026505a380b793
Reviewed-on: https://go-review.googlesource.com/5525
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
Just so that we notice in the future if another hash function is added
without updating this utility function, make it panic when passed an
unknown handshake hash function. (Which should never happen.)
Change-Id: I60a6fc01669441523d8c44e8fbe7ed435e7f04c8
Reviewed-on: https://go-review.googlesource.com/7646
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Joël Stemmer <stemmertech@gmail.com>
crypto/rand.Reader doesn't ensure that short reads don't happen. This
change contains a couple of fixups where io.ReadFull wasn't being used
with it.
Change-Id: I3855b81f5890f2e703112eeea804aeba07b6a6b8
Reviewed-on: https://go-review.googlesource.com/7645
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Commit f1d669aee9 added support for
AES_256_GCM_SHA384 cipher suites as specified in RFC5289. However, it
did not take the arbitrary hash function into account in the TLS client
handshake when using client certificates.
The hashForClientCertificate method always returned SHA256 as its
hashing function, even if it actually used a different one to calculate
its digest. Setting up the connection would eventually fail with the
error "tls: failed to sign handshake with client certificate:
crypto/rsa: input must be hashed message".
Included is an additional test for this specific situation that uses the
SHA384 hash.
Fixes#9808
Change-Id: Iccbf4ab225633471ef897907c208ad31f92855a3
Reviewed-on: https://go-review.googlesource.com/7040
Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
Decrypter is an interface to support opaque private keys that perform
decryption operations. This interface is analogous to the crypto.Signer
interface.
This change introduces the crypto.Decrypter interface and implements
the crypto.Decrypter interface for rsa.PrivateKey with both OAEP and
PKCS#1 v1.5 padding modes.
Change-Id: I433f649f84ed3c2148337d735cafd75f1d94a904
Reviewed-on: https://go-review.googlesource.com/3900
Reviewed-by: Adam Langley <agl@golang.org>
Change-Id: I8b18dc840425b72d7172a35cb0ba004bd156492d
Reviewed-on: https://go-review.googlesource.com/6252
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Previously, we didn't handle absolute DNS names in certificates the same
way as Chromium, and we probably shouldn't diverge from major browsers.
Change-Id: I56a3962ad1002f68b5dbd65ae90991b82c2f5629
Reviewed-on: https://go-review.googlesource.com/5692
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
RFC 6125 now specifies that wildcards are only allowed for the leftmost
label in a pattern: https://tools.ietf.org/html/rfc6125#section-6.4.3.
This change updates Go to match the behaviour of major browsers in this
respect.
Fixes#9834.
Change-Id: I37c10a35177133624568f2e0cf2767533926b04a
Reviewed-on: https://go-review.googlesource.com/5691
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Some servers which misunderstood the point of the CertificateRequest
message send huge reply records. These records are large enough that
they were considered “insane” by the TLS code and rejected.
This change removes the sanity test for record lengths. Although the
maxCiphertext test still remains, just above, which (roughly) enforces
the 16KB protocol limit on record sizes:
https://tools.ietf.org/html/rfc5246#section-6.2.1Fixes#8928.
Change-Id: Idf89a2561b1947325b7ddc2613dc2da638d7d1c9
Reviewed-on: https://go-review.googlesource.com/5690
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
There was a missing continue that caused certificates with critical
certificate-policy extensions to be rejected. Additionally, that code
structure in general was prone to exactly that bug so I changed it
around to hopefully be more robust in the future.
Fixes#9964.
Change-Id: I58fc6ef3a84c1bd292a35b8b700f44ef312ec1c1
Reviewed-on: https://go-review.googlesource.com/5670
Reviewed-by: Andrew Gerrand <adg@golang.org>
This check is expensive and adversely impacts startup times for some
servers with several, large RSA keys.
It was nice to have, but it's not really going to stop a targetted
attack and was never designed to – hopefully people's private keys
aren't attacker controlled!
Overall I think the feeling is that people would rather have the CPU
time back.
Fixes#6626.
Change-Id: I0143a58c9f22381116d4ca2a3bbba0d28575f3e5
Reviewed-on: https://go-review.googlesource.com/5641
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
Applying my post-submit comments from CL 5120.
The rewrite there changed the code from writing to the stack
frame to writing below the stack frame.
Change-Id: Ie7e0563c0c1731fede2bcefeaf3c9d88a0cf4063
Reviewed-on: https://go-review.googlesource.com/5470
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Require a name to be specified when referencing the pseudo-stack.
If you want a real stack offset, use the hardware stack pointer (e.g.,
R13 on arm), not SP.
Fix affected assembly files.
Change-Id: If3545f187a43cdda4acc892000038ec25901132a
Reviewed-on: https://go-review.googlesource.com/5120
Run-TryBot: Rob Pike <r@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
The mechanical edit in the last round managed to miss ROUND1, among
other indgnities.
Change-Id: Ie3e19d00435a9e701b9872167e4bc7756a9fb5a5
Reviewed-on: https://go-review.googlesource.com/4870
Reviewed-by: Minux Ma <minux@golang.org>
Several .s files for ARM had several properties the new assembler will not support.
These include:
- mentioning SP or PC as a hardware register
These are always pseudo-registers except that in some contexts
they're not, and it's confusing because the context should not affect
which register you mean. Change the references to the hardware
registers to be explicit: R13 for SP, R15 for PC.
- constant creation using assignment
The files say a=b when they could instead say #define a b.
There is no reason to have both mechanisms.
- R(0) to refer to R0.
Some macros use this to a great extent. Again, it's easy just to
use a #define to rename a register.
Change-Id: I002335ace8e876c5b63c71c2560533eb835346d2
Reviewed-on: https://go-review.googlesource.com/4822
Reviewed-by: Dave Cheney <dave@cheney.net>
If an absolute domain name (i.e. ends in a '.' like "example.com.") is used
with ssl/tls, the certificate will be reported as invalid. In matchHostnames,
the host and patterns are split on '.' and if the lengths of the resulting
slices do not match, the function returns false. When splitting an absolute
domain name on '.', the slice will have an extra empty string at the end. This
empty string should be discarded before comparison, if present.
Fixes#9828
Change-Id: I0e39674b44a6f93b5024497e76cf1b550832a61d
Reviewed-on: https://go-review.googlesource.com/4380
Reviewed-by: Adam Langley <agl@golang.org>
TryBot: Adam Langley <agl@golang.org>
Only documentation / comment changes. Update references to
point to golang.org permalinks or go.googlesource.com/go.
References in historical release notes under doc are left as is.
Change-Id: Icfc14e4998723e2c2d48f9877a91c5abef6794ea
Reviewed-on: https://go-review.googlesource.com/4060
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Generalizes PRF calculation for TLS 1.2 to support arbitrary hashes (SHA-384 instead of SHA-256).
Testdata were all updated to correspond with the new cipher suites in the handshake.
Change-Id: I3d9fc48c19d1043899e38255a53c80dc952ee08f
Reviewed-on: https://go-review.googlesource.com/3265
Reviewed-by: Adam Langley <agl@golang.org>
Additional elements in a DN can be added in via ExtraNames. This
option can also be used for sorting DN elements in a custom order.
Change-Id: Ie408d332de913dc2a33bdd86433be38abb7b55be
Reviewed-on: https://go-review.googlesource.com/2257
Reviewed-by: Adam Langley <agl@golang.org>
ECDSA is unsafe to use if an entropy source produces predictable
output for the ephemeral nonces. E.g., [Nguyen]. A simple
countermeasure is to hash the secret key, the message, and
entropy together to seed a CSPRNG, from which the ephemeral key
is derived.
Fixes#9452
--
This is a minimalist (in terms of patch size) solution, though
not the most parsimonious in its use of primitives:
- csprng_key = ChopMD-256(SHA2-512(priv.D||entropy||hash))
- reader = AES-256-CTR(k=csprng_key)
This, however, provides at most 128-bit collision-resistance,
so that Adv will have a term related to the number of messages
signed that is significantly worse than plain ECDSA. This does
not seem to be of any practical importance.
ChopMD-256(SHA2-512(x)) is used, rather than SHA2-256(x), for
two sets of reasons:
*Practical:* SHA2-512 has a larger state and 16 more rounds; it
is likely non-generically stronger than SHA2-256. And, AFAIK,
cryptanalysis backs this up. (E.g., [Biryukov] gives a
distinguisher on 47-round SHA2-256 with cost < 2^85.) This is
well below a reasonable security-strength target.
*Theoretical:* [Coron] and [Chang] show that Chop-MD(F(x)) is
indifferentiable from a random oracle for slightly beyond the
birthday barrier. It seems likely that this makes a generic
security proof that this construction remains UF-CMA is
possible in the indifferentiability framework.
--
Many thanks to Payman Mohassel for reviewing this construction;
any mistakes are mine, however. And, as he notes, reusing the
private key in this way means that the generic-group (non-RO)
proof of ECDSA's security given in [Brown] no longer directly
applies.
--
[Brown]: http://www.cacr.math.uwaterloo.ca/techreports/2000/corr2000-54.ps
"Brown. The exact security of ECDSA. 2000"
[Coron]: https://www.cs.nyu.edu/~puniya/papers/merkle.pdf
"Coron et al. Merkle-Damgard revisited. 2005"
[Chang]: https://www.iacr.org/archive/fse2008/50860436/50860436.pdf
"Chang and Nandi. Improved indifferentiability security analysis
of chopMD hash function. 2008"
[Biryukov]: http://www.iacr.org/archive/asiacrypt2011/70730269/70730269.pdf
"Biryukov et al. Second-order differential collisions for reduced
SHA-256. 2011"
[Nguyen]: ftp://ftp.di.ens.fr/pub/users/pnguyen/PubECDSA.ps
"Nguyen and Shparlinski. The insecurity of the elliptic curve
digital signature algorithm with partially known nonces. 2003"
New tests:
TestNonceSafety: Check that signatures are safe even with a
broken entropy source.
TestINDCCA: Check that signatures remain non-deterministic
with a functional entropy source.
Updated "golden" KATs in crypto/tls/testdata that use ECDSA suites.
Change-Id: I55337a2fbec2e42a36ce719bd2184793682d678a
Reviewed-on: https://go-review.googlesource.com/3340
Reviewed-by: Adam Langley <agl@golang.org>
ECDSA is unsafe to use if an entropy source produces predictable
output for the ephemeral nonces. E.g., [Nguyen]. A simple
countermeasure is to hash the secret key, the message, and
entropy together to seed a CSPRNG, from which the ephemeral key
is derived.
--
This is a minimalist (in terms of patch size) solution, though
not the most parsimonious in its use of primitives:
- csprng_key = ChopMD-256(SHA2-512(priv.D||entropy||hash))
- reader = AES-256-CTR(k=csprng_key)
This, however, provides at most 128-bit collision-resistance,
so that Adv will have a term related to the number of messages
signed that is significantly worse than plain ECDSA. This does
not seem to be of any practical importance.
ChopMD-256(SHA2-512(x)) is used, rather than SHA2-256(x), for
two sets of reasons:
*Practical:* SHA2-512 has a larger state and 16 more rounds; it
is likely non-generically stronger than SHA2-256. And, AFAIK,
cryptanalysis backs this up. (E.g., [Biryukov] gives a
distinguisher on 47-round SHA2-256 with cost < 2^85.) This is
well below a reasonable security-strength target.
*Theoretical:* [Coron] and [Chang] show that Chop-MD(F(x)) is
indifferentiable from a random oracle for slightly beyond the
birthday barrier. It seems likely that this makes a generic
security proof that this construction remains UF-CMA is
possible in the indifferentiability framework.
--
Many thanks to Payman Mohassel for reviewing this construction;
any mistakes are mine, however. And, as he notes, reusing the
private key in this way means that the generic-group (non-RO)
proof of ECDSA's security given in [Brown] no longer directly
applies.
--
[Brown]: http://www.cacr.math.uwaterloo.ca/techreports/2000/corr2000-54.ps
"Brown. The exact security of ECDSA. 2000"
[Coron]: https://www.cs.nyu.edu/~puniya/papers/merkle.pdf
"Coron et al. Merkle-Damgard revisited. 2005"
[Chang]: https://www.iacr.org/archive/fse2008/50860436/50860436.pdf
"Chang and Nandi. Improved indifferentiability security analysis
of chopMD hash function. 2008"
[Biryukov]: http://www.iacr.org/archive/asiacrypt2011/70730269/70730269.pdf
"Biryukov et al. Second-order differential collisions for reduced
SHA-256. 2011"
[Nguyen]: ftp://ftp.di.ens.fr/pub/users/pnguyen/PubECDSA.ps
"Nguyen and Shparlinski. The insecurity of the elliptic curve
digital signature algorithm with partially known nonces. 2003"
Fixes#9452
Tests:
TestNonceSafety: Check that signatures are safe even with a
broken entropy source.
TestINDCCA: Check that signatures remain non-deterministic
with a functional entropy source.
Change-Id: Ie7e04057a3a26e6becb80e845ecb5004bb482745
Reviewed-on: https://go-review.googlesource.com/2422
Reviewed-by: Adam Langley <agl@golang.org>
Signer is an interface to support opaque private keys.
These keys typically result from being kept in special hardware
(i.e. a TPM) although sometimes operating systems provide a
similar interface using process isolation for security rather
than hardware boundaries.
This changes provides updates implements crypto.Signer in
CreateCRL and CreateCertificate so that they can be used with
opaque keys.
This CL has been discussed at: http://golang.org/cl/145910043
Change-Id: Id7857fb9a3b4c957c7050b519552ef1c8e55461e
Reviewed-on: https://go-review.googlesource.com/3126
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
According to RFC5280 the authority key identifier extension MUST included in all
CRLs issued. This patch includes the authority key identifier extension when the
Subject Key Identifier is present in the signing certificate.
RFC5280 states:
"The authority key identifier extension provides a means of identifying the
public key corresponding to the private key used to sign a CRL. The
identification can be based on either the key identifier (the subject key
identifier in the CRL signer's certificate) or the issuer name and serial
number. This extension is especially useful where an issuer has more than one
signing key, either due to multiple concurrent key pairs or due to changeover."
Conforming CRL issuers MUST use the key identifier method, and MUST include this
extension in all CRLs issued."
This CL has been discussed at: http://golang.org/cl/177760043
Change-Id: I9bf50521908bfe777ea2398f154c13e8c90d14ad
Reviewed-on: https://go-review.googlesource.com/2258
Reviewed-by: Adam Langley <agl@golang.org>
Signer is an interface to support opaque private keys.
These keys typically result from being kept in special hardware
(i.e. a TPM) although sometimes operating systems provide a
similar interface using process isolation for security rather
than hardware boundaries.
This changes provides updates implements crypto.Signer in
CreateCRL and CreateCertificate so that they can be used with
opaque keys.
This CL has been discussed at: http://golang.org/cl/145910043
Change-Id: Ie4a4a583fb120ff484a5ccf267ecd2a9c5a3902b
Reviewed-on: https://go-review.googlesource.com/2254
Reviewed-by: Adam Langley <agl@golang.org>
Fix SmartOS build that was broken in 682922908f.
SmartOS pretends to be Ubuntu/Debian with respect to its SSL
certificate location.
Change-Id: I5405c6472c8a1e812e472e7301bf6084c17549d6
Reviewed-on: https://go-review.googlesource.com/2704
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
RFC5280 states:
"This optional field describes the version of the encoded CRL. When
extensions are used, as required by this profile, this field MUST be
present and MUST specify version 2 (the integer value is 1)."
This CL has been discussed at: http://golang.org/cl/172560043
Change-Id: I8a72d7593d5ca6714abe9abd6a37437c3b69ab0f
Reviewed-on: https://go-review.googlesource.com/2259
Reviewed-by: Adam Langley <agl@golang.org>
And add names for the curve implemented in crypto/elliptic.
This permits a safer alternative to switching on BitSize
for code that implements curve-dependent cryptosystems.
(E.g., ECDSA on P-xxx curves with the matched SHA-2
instances.)
Change-Id: I653c8f47506648028a99a96ebdff8389b2a95fc1
Reviewed-on: https://go-review.googlesource.com/2133
Reviewed-by: Adam Langley <agl@golang.org>
According to RFC4055 a NULL parameter MUST be present in the signature
algorithm. This patch adds the NULL value to the Signature Algorithm
parameters in the signingParamsForPrivateKey function for RSA based keys.
Section 2.1 states:
"There are two possible encodings for the AlgorithmIdentifier
parameters field associated with these object identifiers. The two
alternatives arise from the loss of the OPTIONAL associated with the
algorithm identifier parameters when the 1988 syntax for
AlgorithmIdentifier was translated into the 1997 syntax. Later the
OPTIONAL was recovered via a defect report, but by then many people
thought that algorithm parameters were mandatory. Because of this
history some implementations encode parameters as a NULL element
while others omit them entirely. The correct encoding is to omit the
parameters field; however, when RSASSA-PSS and RSAES-OAEP were
defined, it was done using the NULL parameters rather than absent
parameters.
All implementations MUST accept both NULL and absent parameters as
legal and equivalent encodings.
To be clear, the following algorithm identifiers are used when a NULL
parameter MUST be present:
sha1Identifier AlgorithmIdentifier ::= { id-sha1, NULL }
sha224Identifier AlgorithmIdentifier ::= { id-sha224, NULL }
sha256Identifier AlgorithmIdentifier ::= { id-sha256, NULL }
sha384Identifier AlgorithmIdentifier ::= { id-sha384, NULL }
sha512Identifier AlgorithmIdentifier ::= { id-sha512, NULL }"
This CL has been discussed at: http://golang.org/cl/177610043
Change-Id: Ic782161938b287f34f64ef5eb1826f0d936f2f71
Reviewed-on: https://go-review.googlesource.com/2256
Reviewed-by: Adam Langley <agl@golang.org>
There are two methods by which TLS clients signal the renegotiation
extension: either a special cipher suite value or a TLS extension.
It appears that I left debugging code in when I landed support for the
extension because there's a "+ 1" in the switch statement that shouldn't
be there.
The effect of this is very small, but it will break Firefox if
security.ssl.require_safe_negotiation is enabled in about:config.
(Although almost nobody does this.)
This change fixes the original bug and adds a test. Sadly the test is a
little complex because there's no OpenSSL s_client option that mirrors
that behaviour of require_safe_negotiation.
Change-Id: Ia6925c7d9bbc0713e7104228a57d2d61d537c07a
Reviewed-on: https://go-review.googlesource.com/1900
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
SignPSS is documented as allowing opts to be nil, but actually
crashes in that case. This change fixes that.
Change-Id: Ic48ff5f698c010a336e2bf720e0f44be1aecafa0
Reviewed-on: https://go-review.googlesource.com/2330
Reviewed-by: Minux Ma <minux@golang.org>
This CL splits the (ever growing) list of ca cert locations by major unix
platforms (darwin, windows and plan9 are already handled seperately).
Although it is clear the unix variants cannot manage to agree on some standard
locations, we can avoid to some extent an artificial ranking of priority
amongst the supported GOOSs.
* Split certFiles definition by GOOS
* Include NetBSD ca cert location
Fixes#9285
Change-Id: I6df2a3fddf3866e71033e01fce43c31e51b48a9e
Reviewed-on: https://go-review.googlesource.com/2208
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Specify what will happen if len(dst) != len(src).
Change-Id: I66afa3730f637753b825189687418f14ddec3629
Reviewed-on: https://go-review.googlesource.com/1754
Reviewed-by: Adam Langley <agl@golang.org>
SSLv3 (the old minimum) is still supported and can be enabled via the
tls.Config, but this change increases the default minimum version to TLS
1.0. This is now common practice in light of the POODLE[1] attack
against SSLv3's CBC padding format.
[1] https://www.imperialviolet.org/2014/10/14/poodle.htmlFixes#9364.
Change-Id: Ibae6666ee038ceee0cb18c339c393155928c6510
Reviewed-on: https://go-review.googlesource.com/1791
Reviewed-by: Minux Ma <minux@golang.org>
Fix TLS_FALLBACK_SCSV check when comparing the client version to the
default max version. This enables the TLS_FALLBACK_SCSV check by default
in servers that do not explicitly set a max version in the tls config.
Change-Id: I5a51f9da6d71b79bc6c2ba45032be51d0f704b5e
Reviewed-on: https://go-review.googlesource.com/1776
Reviewed-by: Adam Langley <agl@golang.org>
A new attack on CBC padding in SSLv3 was released yesterday[1]. Go only
supports SSLv3 as a server, not as a client. An easy fix is to change
the default minimum version to TLS 1.0 but that seems a little much
this late in the 1.4 process as it may break some things.
Thus this patch adds server support for TLS_FALLBACK_SCSV[2] -- a
mechanism for solving the fallback problem overall. Chrome has
implemented this since February and Google has urged others to do so in
light of yesterday's news.
With this change, clients can indicate that they are doing a fallback
connection and Go servers will be able to correctly reject them.
[1] http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html
[2] https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/157090043
In [1] the behaviour of encoding/asn1 with respect to marshaling
optional integers was changed. Previously, a zero valued integer would
be omitted when marshaling. After the change, if a default value was
set then the integer would only be omitted if it was the default value.
This changed the behaviour of crypto/x509 because
Certificate.MaxPathLen has a default value of -1 and thus zero valued
MaxPathLens would no longer be omitted when marshaling. This is
arguably a bug-fix -- a value of zero for MaxPathLen is valid and
meaningful and now could be expressed. However it broke users
(including Docker) who were not setting MaxPathLen at all.
This change again causes a zero-valued MaxPathLen to be omitted and
introduces a ZeroMathPathLen member that indicates that, yes, one
really does want a zero. This is ugly, but we value not breaking users.
[1] https://code.google.com/p/go/source/detail?r=4218b3544610e8d9771b89126553177e32687adf
LGTM=rsc
R=rsc
CC=golang-codereviews, golang-dev
https://golang.org/cl/153420045
The ASN.1 encoding of the CRL Distribution Points extension showed an invalid false 'IsCompound' which caused a display problem in the Windows certificate viewer.
LGTM=agl
R=agl
CC=golang-codereviews
https://golang.org/cl/143320043
On android, root certificates appear to be stored in the folder
/system/etc/security/cacerts, which has many certs in several
different files. This change adds a new array of directories in
which certs can be found.
To test this, I simply tried making a request with the http
library to an HTTPS URL on an android emulator and manually
verified that it worked.
LGTM=crawshaw
R=golang-codereviews, gobot, crawshaw
CC=golang-codereviews
https://golang.org/cl/151800043
