- Dec 08, 2016
-
-
Matt Caswell authored
Perl changes reviewed by Richard Levitte. Non-perl changes reviewed by Rich Salz Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
Perl changes reviewed by Richard Levitte. Non-perl changes reviewed by Rich Salz Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
Perl changes reviewed by Richard Levitte. Non-perl changes reviewed by Rich Salz Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
The _clienthello_ in the extensions parsing functions is overly specific. Better to keep the convention to just _client_ Perl changes reviewed by Richard Levitte. Non-perl changes reviewed by Rich Salz Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
This lays the foundation for a later move to have the extensions built and placed into the correct message for TLSv1.3 (e.g. ServerHello or EncryptedExtensions). Perl changes reviewed by Richard Levitte. Non-perl changes reviewed by Rich Salz Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
Later we will have client extensions code too. Perl changes reviewed by Richard Levitte. Non-perl changes reviewed by Rich Salz Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
Perl changes reviewed by Richard Levitte. Non-perl changes reviewed by Rich Salz Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
Add support for construction of extensions Perl changes reviewed by Richard Levitte. Non-perl changes reviewed by Rich Salz Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
This builds on the work started in 1ab3836b and extends is so that each extension has its own identified parsing functions, as well as an allowed context identifying which messages and protocols it is relevant for. Subsequent commits will do a similar job for the ServerHello extensions. This will enable us to have common functions for processing extension blocks no matter which of the multiple messages they are received from. In TLSv1.3 a number of different messages have extension blocks, and some extensions have moved from one message to another when compared to TLSv1.2. Perl changes reviewed by Richard Levitte. Non-perl changes reviewed by Rich Salz Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
Perl changes reviewed by Richard Levitte. Non-perl changes reviewed by Rich Salz Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
Perl changes reviewed by Richard Levitte. Non-perl changes reviewed by Rich Salz Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
Subsequent commits will pull other extensions code into this file. Perl changes reviewed by Richard Levitte. Non-perl changes reviewed by Rich Salz Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
At this stage the message is just empty. We need to fill it in with extension data. Perl changes reviewed by Richard Levitte. Non-perl changes reviewed by Rich Salz Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
There are some minor differences in the format of a ServerHello in TLSv1.3. Perl changes reviewed by Richard Levitte. Non-perl changes reviewed by Rich Salz Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Richard Levitte authored
If on a non-tty stdin, TTY_get() will fail with errno == ENODEV. We didn't catch that. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2039)
-
Richard Levitte authored
TTY_get() sometimes surprises us with new errno values to determine if we have a controling terminal or not. This generated error is a helpful tool to figure out that this was what happened and what the unknown value is. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2043)
-
Richard Levitte authored
Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2040)
-
- Dec 07, 2016
-
-
Richard Levitte authored
The best way to test the UI interface is currently by using an openssl command that uses password_callback. The only one that does this is 'genrsa'. Since password_callback uses a UI method derived from UI_OpenSSL(), it ensures that one gets tested well enough as well. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2040)
-
Richard Levitte authored
Since there are many parts of UI_process() that can go wrong, it isn't very helpful to only return -1 with no further explanation. With this change, the error message will at least show which part went wrong. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2037)
-
- Dec 05, 2016
-
-
Kurt Roeckx authored
Reviewed-by: Rich Salz <rsalz@openssl.org> GH: #2025
-
Kurt Roeckx authored
Reviewed-by: Rich Salz <rsalz@openssl.org> GH: #2025
-
Matt Caswell authored
Improves the readability of the code, and reduces the liklihood of errors. Also made a few minor style changes. Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Matt Caswell authored
Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Matt Caswell authored
Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Matt Caswell authored
Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Matt Caswell authored
At the moment the msg callback only received the record header with the outer record type in it. We never pass the inner record type - we probably need to at some point. Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Matt Caswell authored
Add some tests for the new record construction Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Matt Caswell authored
Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Matt Caswell authored
Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Matt Caswell authored
Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Matt Caswell authored
Reviewed-by: Rich Salz <rsalz@openssl.org>
-
- Dec 03, 2016
-
-
Viktor Dukhovni authored
Reviewed-by: Matt Caswell <matt@openssl.org>
-
- Dec 02, 2016
-
-
Kurt Roeckx authored
The fuzzers use -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION, and actually get different results based on that. We should have at least some targets that actually fully use the fuzz corpora. Reviewed-by: Rich Salz <rsalz@openssl.org> GH: #2023
-
Kurt Roeckx authored
We want to be in the same global state each time we come in FuzzerTestOneInput(). There are various reasons why we might not be that include: - Initialization that happens on first use. This is mostly the RUN_ONCE() things, or loading of error strings. - Results that get cached. For instance a stack that is sorted, RSA blinding that has been set up, ... So I try to trigger as much as possible in FuzzerInitialize(), and for things I didn't find out how to trigger this it needs to happen in FuzzerTestOneInput(). Reviewed-by: Rich Salz <rsalz@openssl.org> GH: #2023
-
Kurt Roeckx authored
This is something you might want to change depending on the version to use, there is no point in us fixing this to something. Reviewed-by: Rich Salz <rsalz@openssl.org> GH: #2023
-
Kurt Roeckx authored
Reviewed-by: Rich Salz <rsalz@openssl.org> GH: #2023
-
Kurt Roeckx authored
Reviewed-by: Rich Salz <rsalz@openssl.org> GH: #2023
-
Kurt Roeckx authored
Reviewed-by: Rich Salz <rsalz@openssl.org> GH: #2023
-
Kurt Roeckx authored
Reviewed-by: Rich Salz <rsalz@openssl.org> GH: #2023
-
Kurt Roeckx authored
Reviewed-by: Rich Salz <rsalz@openssl.org> GH: #2023
-