Change ssl_find_private_key to void

No caller checks its return value (which is always 0).

Change-Id: I18461ee6e5d369722c8c2b2ea1e409423aa5d631
Reviewed-on: https://code.wireshark.org/review/1365
Reviewed-by: Michael Mann <mmann78@netscape.net>
Reviewed-by: Evan Huus <eapache@gmail.com>
ssl: Reduce chance of hash-collisions SSL private keys

The wildcard address contains all zeroes, resulting in the same hash
for 0.0.0.0 and ::. Not really problematic, but it does not sound
great either.

Change-Id: I099128973a1bd8bb5c88d0abcab3ea4ecc3a96c9
Reviewed-on: https://code.wireshark.org/review/1366
Reviewed-by: Evan Huus <eapache@gmail.com>
ssl: return early if no private keys are found

There is no need to check for private keys if there are none. In
addition, print the number of keys for debugging purposes.

Change-Id: Idc9d650e0bf087c0f647dba4e5bd4920b4f6e228
Reviewed-on: https://code.wireshark.org/review/1367
Reviewed-by: Evan Huus <eapache@gmail.com>
ssl: support any address/port combi for priv key

Both "any port" and "any address" are supported separatedly, but not the
combination of both. This also has the effect that the combination of
any address with the special keyword "start_tls" did not work.

Fix this by checking for a private key with the combination of any
address and port.

Change-Id: Icb49d6728f032a05007dcb7ac73ec0528778441a
Reviewed-on: https://code.wireshark.org/review/1368
Reviewed-by: Evan Huus <eapache@gmail.com>
dtls: run dissector for decryption also on server hello extensions

The dissector only ran through the server hello extensions for the tree
and not in the ssl decryption pass. This resulted in
ssl_dissect_hnd_hello_ext() being always called with ssl == NULL. For
SSL this was also called with ssl != NULL.

Change-Id: I22f7b1089731124b3ca1a2b8515f307c4a021b7f
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Reviewed-on: https://code.wireshark.org/review/1370
Reviewed-by: Evan Huus <eapache@gmail.com>
Fix FSF address.

Change-Id: Ic79fcf7e1bebb9821d9d9db43c2a4f4291beb706
Reviewed-on: https://code.wireshark.org/review/1374
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Have DTLS just dissect the test capture as data

Follow-up to g757db64e484b009c33b67b5fa38e109d7b8f5e78 which changed the filter
being tested but didn't change the target protocol, so the test was still
failing because it was still trying to use HTTP.

Change-Id: I6675cfad3bba63f7a536eb7ae82e4b25132d108e
Reviewed-on: https://code.wireshark.org/review/1375
Reviewed-by: Evan Huus <eapache@gmail.com>