We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks
more like a usual language, CMake believes everything, even "if" and "else", is
just a really really funny function call (a "command").
We should pick something for consistency. Upstream CMake writes "if(FOO)", so
go with that one.
Change-Id: I67e0eb650a52670110b417312a362c9f161c8721
Reviewed-on: https://boringssl-review.googlesource.com/30807
Reviewed-by: Adam Langley <agl@google.com>
On Windows, just switching the socket to blocking doesn't work. Instead,
switch the stdin half of the waiter to waiting for either socket write
or stdin read, depending on whether we're in the middle of trying to
write a buffer.
Change-Id: I81414898f0491e78e6ab5b28c12148a3909ec1e0
Reviewed-on: https://boringssl-review.googlesource.com/28167
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
If the peer sends us one record that exceeds buffer, the socket will no
longer flag as readable, because data has been consumed, but SSL_read
should still be called to drain data. bssl would instead not notice and
only surface the data later on.
This can (currently) be reproduced by sending "HEAD / HTTP/1.1" to
www.google.com.
Change-Id: I73cdbe104ba6be56fc033429999e630f0eb852d8
Reviewed-on: https://boringssl-review.googlesource.com/28166
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
While |WaitForMultipleObjects| works for both sockets and stdin, the
latter is often a line-buffered console. The |HANDLE| is considered
readable if there are any console events available, but reading blocks
until a full line is available. (In POSIX, line buffering is implemented
in the kernel via termios, which is differently concerning, but does
mean |select| works as expected.)
So that |Wait| reflects final stdin read, we spawn a stdin reader thread
that writes to an in-memory buffer and signals a |WSAEVENT| to
coordinate with the socket. This is kind of silly, but it works.
I tried just writing it to a pipe, but it appears
|WaitForMultipleObjects| does not work on pipes!
Change-Id: I2bfa323fa91aad7d2035bb1fe86ee6f54b85d811
Reviewed-on: https://boringssl-review.googlesource.com/28165
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Rather than printing the SSL_ERROR_* constants, print the actual error.
This should be a bit more understandable. Debugging this also uncovered
some other issues on Windows:
- We were mixing up C runtime and Winsock errors, which are separate in
Windows.
- The thread local implementation interferes with WSAGetLastError due to
a quirk of TlsGetValue. This could affect other Windows consumers.
(Chromium uses a custom BIO, so it isn't affected.)
- SocketSetNonBlocking also interferes with WSAGetLastError.
- Listen for FD_CLOSE along with FD_READ. Connection close does not
signal FD_READ. (The select loop only barely works on Windows anyway
due to issues with stdin and line buffering, but if we take stdin out
of the equation, FD_CLOSE can be tested.)
Change-Id: Ia8d42b5ac39ebb3045d410dd768f83a3bb88b2cb
Reviewed-on: https://boringssl-review.googlesource.com/28186
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Rather than printing the SSL_ERROR_* constants, print the actual error.
This should be a bit more understandable. Debugging this also uncovered
some other issues on Windows:
- We were mixing up C runtime and Winsock errors, which are separate in
Windows.
- The thread local implementation interferes with WSAGetLastError due to
a quirk of TlsGetValue. This could affect other Windows consumers.
(Chromium uses a custom BIO, so it isn't affected.)
- SocketSetNonBlocking also interferes with WSAGetLastError.
- Listen for FD_CLOSE along with FD_READ. Connection close does not
signal FD_READ. (The select loop only barely works on Windows anyway
due to issues with stdin and line buffering, but if we take stdin out
of the equation, FD_CLOSE can be tested.)
Change-Id: If991259915acc96606a314fbe795fe6ea1e295e8
Reviewed-on: https://boringssl-review.googlesource.com/28125
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
https://boringssl-review.googlesource.com/10522 didn't actually do what
it was supposed to do. In fact, it appears, not paying attention to it,
we've managed to make RSA verify slower than ECDSA verify. Oops.
Did 32000 RSA 2048 verify (same key) operations in 1016746us (31473.0 ops/sec)
Did 5525 RSA 2048 verify (fresh key) operations in 1067209us (5177.1 ops/sec)
Did 8957 ECDSA P-256 verify operations in 1078570us (8304.5 ops/sec)
The difference is in setting up the BN_MONT_CTX, either computing R^2 or n0.
I'm guessing R^2. The current algorithm needs to be constant-time, but we can
split out a variable-time one if necessary.
Change-Id: Ie064a0e464aaa803815b56a6734bc9e2becef1a7
Reviewed-on: https://boringssl-review.googlesource.com/27244
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This includes a point validation, which figures into the overall cost of
an ECDH operation. If, say, point validation is slow because it uses
generic code, we'd like it to show up in benchmarks.
(Later I'd like to replace this mess with a simple byte-oriented ECDH
API. When that happens, I'll update the benchmark accordingly.)
Change-Id: If8c33542d4b40572aac0a71ea2f658e7bc501f4b
Reviewed-on: https://boringssl-review.googlesource.com/26969
Reviewed-by: Adam Langley <agl@google.com>
Upgrade-Note: SSL_CTX_set_tls13_variant(tls13_experiment) on the server
should switch to SSL_CTX_set_tls13_variant(tls13_experiment2).
(Configuring any TLS 1.3 variants on the server enables all variants,
so this is a no-op. We're just retiring some old experiments.)
Change-Id: I60f0ca3f96ff84bdf59e1a282a46e51d99047462
Reviewed-on: https://boringssl-review.googlesource.com/23784
Commit-Queue: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
We end up writing these switch cases everywhere. Let consumers decompose
these a bit. The original thought was folks should write switch-cases so
they handle everything they support, but that's a pain. As long as
algorithm preferences are always configured, we can still add new
dimensions because folks won't be asked to sign algorithms that depend
on dimensions they don't understand.
Change-Id: I3dd7f067f2c55212f0201876546bc70fee032bcf
Reviewed-on: https://boringssl-review.googlesource.com/22524
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Steven Valdez <svaldez@google.com>
Add a simple dumb webserver that responds with the session status for
any GET request. This option is intended to be used with -loop to
generate automated responses to requests and serves two purposes: (1)
test that application data from clients can be decrypted, (2) test that
clients can decrypt data from the server and (3) early data indicator.
Change-Id: I2b8374ca7b8db4c8effab42e86b5e3139d9466e1
Reviewed-on: https://boringssl-review.googlesource.com/20305
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
SSL_state_string_long and SSL_state_string are often used for debugging
purposes. The latter's 6-letter codes are absurd, but
SSL_state_string_long is plausible. So we don't lose this when
converging state machines or switching to TLS 1.3, add this to TLS 1.3.
Bug: 128
Change-Id: Iec6529a4d9eddcf08bc9610137b4ccf9ea2681a6
Reviewed-on: https://boringssl-review.googlesource.com/19524
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
There are still a ton of them, almost exclusively complaints that
function declaration and definitions have different parameter names. I
just fixed a few randomly.
Change-Id: I1072f3dba8f63372cda92425aa94f4aa9e3911fa
Reviewed-on: https://boringssl-review.googlesource.com/18706
Reviewed-by: Steven Valdez <svaldez@google.com>
TLS 1.3 deployment is currently blocked by buggy middleboxes
throughout the ecosystem. As an experiment to better understand these bugs
and the problems they are causing, implement TLS 1.3 variants with
alternate encodings. These are still the same protocol, only encoded
slightly differently. We will use what we learn from these experiments to
guide the TLS 1.3 deployment strategy and proposals to the IETF, if any.
These experiments only target the basic 1-RTT TLS 1.3 handshake. Based on
what we learn from this experiment, we may try future variations to
explore 0-RTT and HelloRetryRequest.
When enabled, the server supports all TLS 1.3 variants while the client
is configured to use a particular variant.
Change-Id: I532411d1abc41314dc76acce0246879b754b4c61
Reviewed-on: https://boringssl-review.googlesource.com/17327
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Steven Valdez