Due to merging our patched 1.0.1 code with the 1.0.2 code, some parts of
upstream's 25f93585a70fb05bb9f911884ab95e560f662a5d didn't make it into
the code.
https://code.google.com/p/chromium/issues/detail?id=397333
Change-Id: Iceb13e63a7ac91474fd39e7faad11fa52c56185d
Reviewed-on: https://boringssl-review.googlesource.com/1310
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Some EC ASN.1 structures are using a named curve, but include the full
parameters anyway. With this change, BoringSSL will recognise the order
of the curve.
Change-Id: Iff057178453f9fdc98c8c03bcabbccef89709887
Reviewed-on: https://boringssl-review.googlesource.com/1270
Reviewed-by: Adam Langley <agl@google.com>
Custom RSA and ECDSA keys may not expose the key material. Plumb and "opaque"
bit out of the *_METHOD up to EVP_PKEY. Query that in ssl_rsa.c to skip the
sanity checks for certificate and key matching.
Change-Id: I362a2d5116bfd1803560dfca1d69a91153e895fc
Reviewed-on: https://boringssl-review.googlesource.com/1255
Reviewed-by: Adam Langley <agl@google.com>
It's unused with SSLv2 gone. Also, being a decryption padding check, it really
should be constant-time and isn't.
Change-Id: I96be02cb50f9bf0229b9174eccd80fa338bf8e3e
Reviewed-on: https://boringssl-review.googlesource.com/1254
Reviewed-by: Adam Langley <agl@google.com>
More signed/unsigned issues, and some other missing checks.
Change-Id: Ib64429a609ca2d64b74a4744092aac67ad0af4e5
Reviewed-on: https://boringssl-review.googlesource.com/1252
Reviewed-by: Adam Langley <agl@google.com>
On OS X, the length must be the length of the address and not of
sockaddr_storage.
Change-Id: Id962f2f3268f07327724b9867a83c15ec50cb9fd
Reviewed-on: https://boringssl-review.googlesource.com/1251
Reviewed-by: Adam Langley <agl@google.com>
Fix base64_test.c to account for this.
Change-Id: I0b3e8062a2130fb01a7e6f175968484769c406f9
Reviewed-on: https://boringssl-review.googlesource.com/1250
Reviewed-by: Adam Langley <agl@google.com>
Appease the Chromium build on OS X.
Change-Id: Idb7466b4d3e4cc9161cd09066b2f79a6290838b1
Reviewed-on: https://boringssl-review.googlesource.com/1240
Reviewed-by: Adam Langley <agl@google.com>
Another signedness error. Leave a TODO to possibly resolve EVP_DecodeBlock's
ignoring padding. Document some of the Init/Update/Finish versions' behavior.
Change-Id: I78a72c3163f8543172a7008b2d09fb10e003d957
Reviewed-on: https://boringssl-review.googlesource.com/1230
Reviewed-by: Adam Langley <agl@google.com>
When I switched the base64 code to use size_t, I missed that one of the
loops was counting down, not up, and depended on the loop variable going
negative.
Additionally this change fixes a bug in NETSCAPE_SPKI_b64_encode where
the size of the result buffer was incorrectly calculated and a possible
memory leak.
Change-Id: Ibdf644244291274f50b314f3bb13a61b46858ca1
Reviewed-on: https://boringssl-review.googlesource.com/1220
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
These were omitted, but are needed by Chromium now.
Change-Id: I17e1672674311c8dc2ede21539c82b8e2e50f376
Reviewed-on: https://boringssl-review.googlesource.com/1201
Reviewed-by: Adam Langley <agl@google.com>
The |size| method was documented to return the same as |ECDSA_size| -
the max size of an ECDSA signature. However, this involves some ASN.1
calculations which is best done once. What custom implementations want
to give is the size of the group order on which the ASN.1 computations
are based.
This change switches the |size| method to allow that.
Change-Id: I95b6e0c2b52bfcd0d74850c2c4e9bc01269255e2
Reviewed-on: https://boringssl-review.googlesource.com/1200
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Also fix some DTLS cookie bugs. rcvd_cookie is never referenced after being
saved (and the length isn't saved, so it couldn't be used anyway), and the
cookie verification failed to check the length.
For convenience, add a CBS_mem_equal helper function. Saves a bit of
repetition.
Change-Id: I187137733b069f0ac8d8b1bf151eeb80d388b971
Reviewed-on: https://boringssl-review.googlesource.com/1174
Reviewed-by: Adam Langley <agl@google.com>
Also tidy up some variable names and update RSA_verify call for it no longer
returning -1. Add CBS helper functions for dealing with C strings.
Change-Id: Ibc398d27714744f5d99d4f94ae38210cbc89471a
Reviewed-on: https://boringssl-review.googlesource.com/1164
Reviewed-by: Adam Langley <agl@google.com>
Previously, public headers lived next to the respective code and there
were symlinks from include/openssl to them.
This doesn't work on Windows.
This change moves the headers to live in include/openssl. In cases where
some symlinks pointed to the same header, I've added a file that just
includes the intended target. These cases are all for backwards-compat.
Change-Id: I6e285b74caf621c644b5168a4877db226b07fd92
Reviewed-on: https://boringssl-review.googlesource.com/1180
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
PNaCl needs OPENSSL_NO_ASM to work and a couple of cases were missing
because it hasn't previously been tested.
Additionally, it defined _BSD_SOURCE and others on the command line,
causing duplicate definition errors when defined in source code.
It's missing readdir_r.
It uses newlib, which appears to use u_short in socket.h without ever
defining it.
Change-Id: Ieccfc7365723d0521f6327eebe9f44a2afc57406
Reviewed-on: https://boringssl-review.googlesource.com/1140
Reviewed-by: Adam Langley <agl@google.com>
This is to avoid having to copy over the RSA modulus in all of Chromium's
platform-specific keys.
Change-Id: I20bf22446a5cfb633b900c3b392b7a1da81a5431
Reviewed-on: https://boringssl-review.googlesource.com/1151
Reviewed-by: Adam Langley <agl@google.com>
Match the other EVP_DigestSignFinal implementations. Fix the instances in
ssl/t1_enc.c which were not following the EVP_DigestSignFinal contract; on
entry, *out_len should contain the size of the buffer.
Change-Id: Icd44d97a4c98704dea975798c0101d5a37274d17
Reviewed-on: https://boringssl-review.googlesource.com/1130
Reviewed-by: Adam Langley <agl@google.com>
Converting check_autoarg from a macro to a function lost the behavior. Instead,
just move the logic into p_rsa.c which was the only EVP_PKEY implementation
that even needed the flag.
Also document this behavior on each of the functions. Make note of the out =
NULL case only returning the maximum output size, and not necessarily the
actual size.
For testing, update example_sign to determine the signature size using the NULL
behavior rather than querying the RSA key.
Change-Id: Iec6c2862028a5cfdefe8faa0e8c471755070898a
Reviewed-on: https://boringssl-review.googlesource.com/1121
Reviewed-by: Adam Langley <agl@google.com>
Building without RSA support is unreasonable. Changes were made by
running
find . -type f -name *.c | xargs unifdef -m -U OPENSSL_NO_RSA
find . -type f -name *.h | xargs unifdef -m -U OPENSSL_NO_RSA
using unifdef 2.10 and some newlines were removed manually.
Change-Id: Iea559e2d4b3d1053f28a4a9cc2f7a3d1f6cabd61
Reviewed-on: https://boringssl-review.googlesource.com/1095
Reviewed-by: Adam Langley <agl@google.com>
Since crypto/ebcdic.{c,h} are not present in BoringSSL, remove the #ifdefs
Changes were made by running
find . -type f -name *.c | xargs unifdef -m -U CHARSET_EBCDIC
find . -type f -name *.h | xargs unifdef -m -U CHARSET_EBCDIC
using unifdef 2.10.
An additional two ifdefs (CHARSET_EBCDIC_not) were removed manually.
Change-Id: Ie174bb00782cc44c63b0f9fab69619b3a9f66d42
Reviewed-on: https://boringssl-review.googlesource.com/1093
Reviewed-by: Adam Langley <agl@google.com>
(This appears to be the case with upstream too, it's not that BoringSSL
is missing optimisations from what I can see.)
Change-Id: I0e54762ef0d09e60994ec82c5cca1ff0b3b23ea4
Reviewed-on: https://boringssl-review.googlesource.com/1080
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
It was removed in the fork but it turned out to need it.
Change-Id: I21030c8d5befecb63f2c40a59963bec1da1d96fb
Reviewed-on: https://boringssl-review.googlesource.com/1081
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
I have confirmed with Dr. Stephen Henson (the author) that the file is
licensed under the OpenSSL license.
Change-Id: I97dc4c74b363184e1b36e5835bad684d66696d54
This change adds the stitched RC4-MD5 code from upstream OpenSSL but
exposes it as an AEAD. It's not a normal AEAD (it's stateful thus
doesn't take an nonce) but forcing pre-AEAD cipher suites in the AEAD
interface is less painful than forcing AEADs into the EVP_CIPHER
interface. Over time, more and more cipher suites will be exposed as
TLS-specific AEADs and then ssl/ can drop support for EVP_CIPHER.
See original code from upstream:
https://github.com/openssl/openssl/blob/master/crypto/evp/e_rc4_hmac_md5.c
Change-Id: Ia9267b224747f02be6b934ea0b2b50e1f529fab9
Reviewed-on: https://boringssl-review.googlesource.com/1043
Reviewed-by: Adam Langley <agl@google.com>
Fixes one comment that mentioned the wrong function name. Also causes
two BN random functions to fail when the output is NULL. Previously they
would silently do nothing.
Change-Id: I89796ab855ea32787765c301a478352287e61190
This gives us systematic bounds-checking on all the parses. Also adds a
convenience function, CBS_memdup, for saving the current contents of a CBS.
Change-Id: I17dad74575f03121aee3f771037b8806ff99d0c3
Reviewed-on: https://boringssl-review.googlesource.com/1031
Reviewed-by: Adam Langley <agl@google.com>
Since all AEAD ciphers now go through EVP_AEAD interface, the code which
uses EVP_Cipher interface no longer needs any of AEAD handling logic.
This also removes EVP_CTRL_AEAD_TLS1_AAD from GCM interface, which was
duplicating non-TLS-specific GCM logic and is not used anymore.
Change-Id: I5ddae880e7bc921337f9149a0acfdd00c9a478c3
aead_test reads test vectors from a file but used blank lines to
indicate the end of a test case. If the file ended without a blank line
to terminate the final test case, it would previously have been skipped.
Change-Id: Id8dd34e86f0b912596dfb33234a894f8d9aa0235
Apart from the obvious little issues, this also works around a
(seeming) libtool/linker:
a.c defines a symbol:
int kFoo;
b.c uses it:
extern int kFoo;
int f() {
return kFoo;
}
compile them:
$ gcc -c a.c
$ gcc -c b.c
and create a dummy main in order to run it, main.c:
int f();
int main() {
return f();
}
this works as expected:
$ gcc main.c a.o b.o
but, if we make an archive:
$ ar q lib.a a.o b.o
and use that:
$ gcc main.c lib.a
Undefined symbols for architecture x86_64
"_kFoo", referenced from:
_f in lib.a(b.o)
(It doesn't matter what order the .o files are put into the .a)
Linux and Windows don't seem to have this problem.
nm on a.o shows that the symbol is of type "C", which is a "common symbol"[1].
Basically the linker will merge multiple common symbol definitions together.
If ones makes a.c read:
int kFoo = 0;
Then one gets a type "D" symbol - a "data section symbol" and everything works
just fine.
This might actually be a libtool bug instead of an ld bug: Looking at `xxd
lib.a | less`, the __.SYMDEF SORTED index at the beginning of the archive
doesn't contain an entry for kFoo unless initialised.
Change-Id: I4cdad9ba46e9919221c3cbd79637508959359427
Now that the consuming code in ssl/ is removed, there is no need for this.
Leave SSL_COMP and STACK_OF(SSL_COMP) for now so as not to break any code which
manipulates the output of SSL_COMP_get_compression_methods to disable
compression.
Change-Id: Idf0a5debd96589ef6e7e56acf5d9259412b7d7a1
Previously we generated a number that was 8 bytes too large and used a
modular reduction, which has a (tiny, tiny) bias towards zero.
Out of an excess of caution, instead truncate the generated nonce and
try again if it's out of range.
Change-Id: Ia9a7a57dd6d3e5f13d0b881b3e9b2e986d46e4ca
The function was hard-coded to 20 rounds already so the argument was
already useless. Thanks to Huzaifa Sidhpurwala for noticing.
Change-Id: I5f9d6ca6d46c6ab769b19820f8f918349544846d
Ensure the library can find the right files under /etc/ssl/certs when
running on older systems.
There are many symbolic links under /etc/ssl/certs created by using
hash of the PEM certificates in order for OpenSSL to find those
certificates. Openssl has a tool to help you create hash symbolic
links (tools/c_rehash). However newer versions of the library changed
the hash algorithm, which makes it unable to run properly on systems
that use the old /etc/ssl/certs layout (e.g. Ubuntu Lucid).
This patch gives a way to find a certificate according to its hash by
using both the old and new algorithms. http://crbug.com/111045 is used
to track this issue.
(Imported from Chromium:
http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/openssl/patches.chromium/0003-x509_hash_name_algorithm_change.patch?revision=231571)
Change-Id: Idbc27aba7685c991f8b94cfea38cf4f3f4b38adc
Windows has different names for these functions and also doesn't have
the strings.h header in which they appear.
This change adds tiny wrapper functions for Windows.
A client reference identity of ".example.com" matches a server certificate
presented identity that is any sub-domain of "example.com" (e.g.
"www.sub.example.com).
With the X509_CHECK_FLAG_SINGLE_LABEL_SUBDOMAINS flag, it matches only direct
child sub-domains (e.g. "www.sub.example.com"). (cherry picked from commit
e52c52f10bb8e34aaf8f28f3e5b56939e8f6b357)
(Imported from upstream's 3cc8a3f2343cda796de90c127b9e907ca3ec2da5)
