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>
Change preferences - always want to try to decrypt signalling PDUs

Change-Id: Ib34f12b5f8dd276612aed2fe0192c94e847858f2
Reviewed-on: https://code.wireshark.org/review/1377
Reviewed-by: Martin Mathieson <martin.r.mathieson@googlemail.com>
SSL: fix compilation without GnuTLS and Gcrypt

Change-Id: Ic783f9ac2b7abcbace67ce48239b0506ac237267
Reviewed-on: https://code.wireshark.org/review/1381
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
T38: fix access to uninitialised variables

Bug: 10050
Change-Id: I7bc2d1b99bcb1241705a2561d9360a006fb9cb47
Reviewed-on: https://code.wireshark.org/review/1382
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
Limit the start of HTTP request/response to a printable character.

From Martin Mathieson.

In a profiled run with FTP traffic, the HTTP dissector looking for the end of a line of data (which was binary) was taking around 3% of runtime.

bug:8822
Change-Id: I2617d1e49030bd5ad85b0e818c48c01dc6fae075
Reviewed-on: https://code.wireshark.org/review/1373
Reviewed-by: Michael Mann <mmann78@netscape.net>
SAP: fix dissection of Originating Source address

Regression introduced in commit c131f9a0745f6307a5c910d8486eb9a37a05935c

Bug: 10029
Change-Id: Ia99ca36216dd26e41f926cc67e52827e665c40eb
Reviewed-on: https://code.wireshark.org/review/1383
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
[Automatic manuf, services and enterprise-numbers update for 2014-04-27]

Change-Id: I0745df4a0a0447abf7ab4c7555d9d195ac40eb78
Reviewed-on: https://code.wireshark.org/review/1384
Reviewed-by: Gerald Combs <gerald@wireshark.org>
http: Display a list of cookies

For long cookies, the label "[truncated] Cookie: foo=v..." is not really
helpful. Add a new subtree to display individual cookies, this makes
copying values much easier.

A new "http.cookie_pair" field was added instead of re-using
"http.cookie". This has the advantage that `tshark -Tfields -e
http.cookie` does not end up with duplicates. At the same time, one can
match against individual cookie values.

I also considered to limit the number of cookies to be split, but as
there is no limit on the number of headers, I decided not to be
restrictive for cookies either.

Change-Id: I98d9522867811278ade3e04aab02e517f997928b
Reviewed-on: https://code.wireshark.org/review/1186
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Evan Huus <eapache@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
ssl/dtls: add keyfile support to dtls

This moves the keyfile and psk options from the ssl code into ssl-utils
and then uses them also for dtls.

This is the last missing part for bug 9499 from my side.

Change-Id: Ie2fe5bc565eabe1e6ce62498c985b8a36e913b0f
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Reviewed-on: https://code.wireshark.org/review/1369
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Michael Mann <mmann78@netscape.net>
http: Fix src/dest mapping for proxied connections

Using value_is_in_range is making quite some assumptions, namely (1) the
proxy server is always run on a registered HTTP port, and (2) the
source (client) port is always not HTTP. The former is quite a strong
assertion which fails to hold when using a custom port (8008) that got
detected through heuristics.

Fix this by recording the source address and port pair for the server
and then check this against the current packet.

This fixes detection of a SSL conversation where two conversations got
detected instead of one. Example: 8008 is proxy, 443 is target server.
Now the proxied conversation got detected as 443 --> "client port"
(server to client, ok) and 443 --> 8008 (client to server, not ok,
should be "client port" --> 443).

bug:7717
Change-Id: I05113ec2aca6c9296184759a8a62eb32cbfcbb4f
Reviewed-on: https://code.wireshark.org/review/1380
Reviewed-by: Michael Mann <mmann78@netscape.net>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
prefs: fix ASAN error due to invalid indirection

For pref_current, indirection of pref->varp.string will cause a read of
size 8. This will cause a global buffer overflow error for all smaller
types, for example lbmc_use_heuristic_subdissectors (size 4).

Reproduce: compile Wireshark with -fsanitize=address, open Preferences
and select OK or Apply. Result: ASAN crash.

To fix this, only indirect a pointer if the storage size is known, a
void pointer stores the address of the constant value (pref_default,
pref_stashed) or the address to the value (pref_current). Note that
pointers of different types are of equal size, I could take
valp.pref_(anything).

While at it, remove superfluous 'break' keywords where a 'return'
keyword is present.

Change-Id: I05a69e8f14a1ecb4e5d2a0c0f0b71ed3f0a41d70
Reviewed-on: https://code.wireshark.org/review/1286
Reviewed-by: Evan Huus <eapache@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Try to fix Mac OS X buildbot
packet-http.c:2629: warning: implicit conversion shortens 64-bit value into a 32-bit value

Change-Id: I6a423639a53c24431fcfd79e0a235f2885ea86c2
Reviewed-on: https://code.wireshark.org/review/1389
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reorder fields in http_conv_t to save some memory.

On amd64 before patch: sizeof(http_conv_t) == 88, after: 72 bytes.

Change-Id: I2863f1c7223a904dadfbe68dc41bc61fc2cc378a
Reviewed-on: https://code.wireshark.org/review/1388
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Fix warning found by -Wunused-const-variable (Clang 3.5)

packet-gvcp.c:493:27: error: unused variable 'linkconfiguration_class' [-Werror,-Wunused-const-variable]

Change-Id: Id31ced029af9700f47230df4afa5c0a4aaecf6d3
Reviewed-on: https://code.wireshark.org/review/1392
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>