I ran into an issue with PSK reading the key as ascii instead of hex. I had a gnutls-serv and gnutls-cli set up with a hex key, and I switched the server for one wrapped using stunnel, but using the same key in psk.txt was failing. I eventually got it working by converting the hex characters to binary and placing that in the contents of the file specified by PSKsecrets (psk.txt), but this won't work for certain scenarios. For example, what if the key contains ascii newline characters?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 29.10.2015 00:12, Reese Wilson wrote:
I ran into an issue with PSK reading the key as ascii instead of hex. I had a gnutls-serv and gnutls-cli set up with a hex key, and I switched the server for one wrapped using stunnel, but using the same key in psk.txt was failing. I eventually got it working by converting the hex characters to binary and placing that in the contents of the file specified by PSKsecrets (psk.txt), but this won't work for certain scenarios. For example, what if the key contains ascii newline characters?
Do it the other way around: generate sufficiently long printable ASCII pre-shared keys, and then hex-encode them for applications that require hex-encoded pre-shared keys. The same applies to any other encoding (base64, rot13, etc.).
Yes, the interface of stunnel restricts the subset of bytes that may be used for pre-shared keys (but not the length of those keys). Yes, this may require generating new pre-shared keys when you migrate to stunnel from another product. Yes, I consider this to be a feature. You can use passphrases or your favourite password generator to generate pre-shared keys for stunnel. Changing the pre-shared key when you migrate to stunnel is also *good* for your security.
Mike
-
Michal Trojnara -
Reese Wilson