| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D1583
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D1441
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D1565
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D1554
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D1486
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D1552
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D1553
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D1528
|
|
|
|
|
|
| |
RecordSizeDefaultsTest, r=mt
Differential Revision: https://phabricator.services.mozilla.com/D1527
|
|
|
|
|
|
|
|
|
| |
Reviewers: mt
Tags: #secure-revision
Differential Revision: https://phabricator.services.mozilla.com/D1517
|
|
|
|
|
|
|
|
|
|
| |
Summary: See draft-ietf-tls-record-limit for details.
Reviewers: ekr
Bug #: 1396487
Differential Revision: https://phabricator.services.mozilla.com/D23
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Crashes for a particular hang have been spiking in the last month, and
all the crashes are associated with macOS 10.12 and 10.13. The crashes
look like this:
Thread 1: waiting on a condition variable in nssSlot_IsTokenPresent
Thread 2: waiting on the (contended) lock in nssSlot_IsTokenPresent
Thread 3: waiting on the (contended) lock in nssSlot_IsTokenPresent
Thread 2 and 3 are waiting on the lock associated with the condition
variable that thread 1 is holding.
One would expect that thread 1 would drop the lock associated with the
condition variable when the wait occurs, and enable thread 2 or thread 3
to make progress. But the particular wait in question passes a
(relative) timeout of zero (which corresponds to what would be
PR_INTERVAL_NO_WAIT), which is unusual in NSS code and condition
variable-using programs in general.
A relative timeout of zero on macOS needs to be translated to an
absolute time for the underlying API, pthread_cond_timedwait. What
appears to be happening is that some absolute time, $NOW, is determined
before calling pthread_cond_timedwait. We then call into
pthread_cond_timedwait and do whatever work we need to do before
checking whether the specified time ($NOW) has passed. Of course it
has; we are at some time $NOW + epsilon, and so the wait times out.
The wait appears to time out without the lock ever being released; if
the lock was released, even if ever-so-shortly, presumably one of the
other threads would be able to make progress. Since the hang only
occurs on macOS 10.12 and 10.13, we are assuming that there was some
change in the condition variable code that attempts to optimize
extremely short timeouts, or treats timeouts of zero differently (even
if inadvertently). The other possibility is this is the way macOS has
always worked, and the crash data we have is only for those versions of
the operating system.
In any event, there's no need to specify a timeout of zero here. We can
specify an "infinite" wait instead (PR_INTERVAL_NO_TIMEOUT) and let
another thread make progress, waking us up when it is done.
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: franziskus
Reviewed By: franziskus
Bug #: 1464778
Differential Revision: https://phabricator.services.mozilla.com/D1433
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: mt
Tags: #secure-revision
Bug #: 1457716
Differential Revision: https://phabricator.services.mozilla.com/D1062
|
| |
|
| |
|
|
|
|
| |
NSPR function PL_strncasecmp
|
|
|
|
| |
adding a test, r=rrelyea
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a nasty one. I was having trouble with tstclnt when testing against
other implementations. It would hang.
I made similar changes to that for kazuho and picotls, where the input file is
read for every connection. So, I did that here too and it also worked nicely.
In order to get 0-RTT working though, I needed to teach ssl_Poll about 0-RTT.
Luckily, there was code already there for that and it just needed a tweak.
The only thing I ran into here was that boringssl (the server I was using to
test against here), was too fast. By the time we had written out the
ClientHello, it had produced a response and we would complete the handshake
before leaving the handshake loop in ssl3_Do1stHandshake(). That meant that we
would never actually send any 0-RTT data, either before or after this patch.
Adding a sleep(1) to the handshake in boringssl did the trick and I could show
that we can send data before the handshake completes. Nothing really
actionable here unless you can think of ways to make our handshake more
performant. Mostly just information.
Separately, people have noticed that tstclnt writes 0-RTT after the first round
trip. That's a symptom of not retaining the poll on write.
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: jcj
Reviewed By: jcj
Bug #: 1463379
Differential Revision: https://phabricator.services.mozilla.com/D1347
|
| |
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D1295
|
| |
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D1212
|
|
|
|
| |
r=ekr,ttaubert
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: mt
Reviewed By: mt
Bug #: 1454367
Differential Revision: https://phabricator.services.mozilla.com/D951
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
r=franziskus
Reviewers: franziskus
Reviewed By: franziskus
Bug #: 1461623
Differential Revision: https://phabricator.services.mozilla.com/D1284
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D1271
|
|
|
|
| |
completes, r=ekr
|
| |
|
| |
|
|
|
|
| |
unchanged on repeated import attempts, r=kaie
|
|
|
|
| |
and speed measuring, r=rrelyea
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
TLS 1.3 explicitly changed to allow close_notify on one half of the
connection. Since SSL, an endpoint was required to send close_notify if it
received close_notify. The general agreement was that this was a silly
requirement and that we would remove it and allow one side of the connection to
be closed. This is critical for some protocols that are being moved to use
TLS.
NSS was almost perfect here. The only problem was that it suppressed the
second close_notify. I've added a test for that.
Reviewers: ttaubert, ekr
Reviewed By: ttaubert, ekr
Subscribers: ekr
Bug #: 1423043
Differential Revision: https://phabricator.services.mozilla.com/D797
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Just moving things about. Also, the comment was outdated.
Reviewers: franziskus
Reviewed By: franziskus
Bug #: 1452855
Differential Revision: https://phabricator.services.mozilla.com/D892
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
ServerKeyExchange.Signature.algorithm values r=mt
Reviewers: mt
Reviewed By: mt
Bug #: 1454321
Differential Revision: https://phabricator.services.mozilla.com/D947
|
|
|
|
| |
obtaining entropy, r=fkiefer
|
|
|
|
| |
DONTBUILD
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: I probably messed this one up.
Reviewers: ekr
Reviewed By: ekr
Bug #: 1453586
Differential Revision: https://phabricator.services.mozilla.com/D919
|
|
|
|
| |
database opening using the sqlite3_open_v2 API, r=dueno
|
| |
|