Category Archives: computer

Using both ECC and RSA keys with Oracle Unified Directory

Something technical again, for once. While I was reviewing the new minimum standards recommended by the German Bundesamt für Sicherheit in der Informationstechnologie and checking the lists of TLS ciphers accepted by certain instances of the Oracle Unified Directory (OUD) I manage, I have to admit I only realised for the first time how the ciphers suites you can actually use depend on the certificate you have, or more properly the type of private key you have and then got stamped by a CA.

Turns out if you want to support ciphers suites that don’t use RSA at all, you cannot be using an RSA private key, either (doh … yes, well.) Arguably, I’m not convinced it’s as important to offer alternatives where the authentication part is concerned, but if you configure your server to only support strong ciphers and then only half of those are actually usable, because you don’t have the corresponding private key for the other half, that may at some point cause problems with supporting a broad range of clients. Therefore, and because it’s not actually explained in the Oracle documentation anywhere, here’s how to get the best of both worlds.

If you feel like you want to research the background of all this some more first, these links helped me:

  • HashedOut by the SSLStore (Everything I’m talking about, here, appertains to the parts of the cipher suite name colour-coded green, there.)
  • OWASP
  • Hackernoon (this is about nginx but describes the same challenge, there called hybrid setup.)

TLDR: To get OUD to support both an ECC and an RSA certificate, the key is to let the server decide, i. e. to NOT set a certificate nickname to use on the definition of the connection handler.

The complete procedure is this:

  • Create both keys, e. g.:
    • openssl genrsa -out example.rsa.key 2048
    • openssl ecparam -genkey -name secp384r1 | openssl ec -out example.ecc.key
  • Get certificates for your keys
    • If you’re trying this out, check this page on how to use openssl ca, (I skipped the intermediate CA bit) e. g.:
      • openssl req -config openssl.cnf -key ~/example.ecc.key -new -sha256 -out example.eccWithRsa.csr
      • openssl req -config openssl.cnf -key ~/example.rsa.key -new -sha256 -out example.rsa.csr
      • openssl ca -config openssl.cnf -extensions server_cert -days 375 -notext -md sha256 -in example.rsa.csr -out certs/example.rsa.pem
      • openssl ca -config openssl.cnf -extensions server_cert -days 375 -notext -md sha256 -in example.eccWithRsa.csr -out certs/example.eccWithRsa.pem
  • Import certificates and private keys into your keystore
    • cat ca/certs/ca.cert.rsa.pem ca/certs/example.eccWithRsa.pem > chain.eccWithRsa.pem
    • cat ca/certs/ca.cert.rsa.pem ca/certs/example.rsa.pem > chain.rsa.pem
    • openssl pkcs12 -export -inkey example.ecc.key -in chain.eccWithRsa.pem -name oud.eccWithRsa -out oud.eccWithRsa.p12
    • openssl pkcs12 -export -inkey example.rsa.key -in chain.rsa.pem -name oud.rsa -out oud.rsa.p12
    • keytool -importkeystore -srckeystore oud.eccWithRsa.p12 -srcstoretype pkcs12 -destkeystore oud.jks -deststoretype pkcs12
    • keytool -importkeystore -srckeystore oud.rsa.p12 -srcstoretype pkcs12 -destkeystore oud.jks 
  • Configure your connection handler
    • bin/dsconfig -h debian -p 4444 -D cn=dirmanager -j ~/pass set-connection-handler-prop --handler-name "LDAPS Connection Handler" --reset ssl-cert-nickname

One thing to note here: The example commands are from my later tests where I explicitly tested getting an ECC key signed by a CA that does NOT have an ECC CA key, itself. That’s what eccWithRsa means in the examples above: An ECC key signed with RSA. And you can see from the lines where the certificate chain is created and then imported into the keystore that we are definitely adding ca.cert.rsa.pem to the chain. I explicitly wanted to test this, because I might need to order certificates from a CA that does not have ECC signing certificates. Turns out this works like a charm, at least for TLS 1.2. It might not work for TLS 1.1, ref. RFC5246 cap. 7.4.2:

If the client provided a “signature_algorithms” extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension. Note that this implies that a certificate containing a key for one signature algorithm MAY be signed using a different signature algorithm (for instance, an RSA key signed with a DSA key). This is a departure from TLS 1.1, which required that the algorithms be the same. Note that this also implies that the DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the algorithm used to sign the certificate. Fixed DH certificates MAY be signed with any hash/signature algorithm pair appearing in the extension. The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are historical.

Verify that everything works as expected:

First, let’s try an EC suite that also uses ECDSA for authentication. The certificate is signed by an RSA CA and validated against that CA cert, though.

% openssl s_client -connect 192.168.56.101:1636 -tls1_2 -cipher ECDHE-
ECDSA-AES256-GCM-SHA384 
-CAfile /Users/khb/ca.cert.rsa.pem -servername debian.example.com 
CONNECTED(00000003)
depth=1 C = DE, ST = Hassia, O = ACME, CN = ACME CA
verify return:1
depth=0 C = DE, ST = Hassia, O = KHB, OU = ecc with rsa, CN = debian.example.com
verify return:1
---
Certificate chain
 0 s:C = DE, ST = Hassia, O = KHB, OU = ecc with rsa, CN = debian.example.com
   i:C = DE, ST = Hassia, O = ACME, CN = ACME CA
 1 s:C = DE, ST = Hassia, O = ACME, CN = ACME CA
   i:C = DE, ST = Hassia, O = ACME, CN = ACME CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEqzCCApOgAwIBAgICEAEwDQYJKoZIhvcNAQELBQAwPzELMAkGA1UEBhMCREUx
...
aAE=
-----END CERTIFICATE-----
subject=C = DE, ST = Hassia, O = KHB, OU = ecc with rsa, CN = debian.example.com


issuer=C = DE, ST = Hassia, O = ACME, CN = ACME CA


---
Acceptable client certificate CA names
C = DE, ST = Hassia, L = Test, O = KHB, CN = debian.example.com
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: ECDSA+SHA512:RSA+SHA512:ECDSA+SHA384:RSA+SHA384:ECDSA+SHA256:RSA+SHA256:DSA+SHA256:ECDSA+SHA224:RSA+SHA224:DSA+SHA224:ECDSA+SHA1:RSA+SHA1:DSA+SHA1
Shared Requested Signature Algorithms: ECDSA+SHA512:RSA+SHA512:ECDSA+SHA384:RSA+SHA384:ECDSA+SHA256:RSA+SHA256:DSA+SHA256:ECDSA+SHA224:RSA+SHA224:DSA+SHA224:ECDSA+SHA1:RSA+SHA1:DSA+SHA1
Peer signing digest: SHA256
Peer signature type: 
ECDSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3063 bytes and written 307 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-
ECDSA-AES256-GCM-SHA384
Server public key is 384 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-ECDSA-AES256-GCM-SHA384
    Session-ID: 5E4E5EDC0C144D514F5FA54E50530C19D0EB98C384E2F7482E680D2532CD6D0F
    Session-ID-ctx: 
    Master-Key: B27BDAE231540A08F32C8BEABB50B286AD2EDCFA0A3CE86A50ED707D92D15DE05ABAE86A1B5790949350B4334E8077E2
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1582194397
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: yes
---
^C

Next, try an RSA suite:

% openssl s_client -connect 192.168.56.101:1636 -tls1_2 -cipher DHE-
RSA
-AES128-GCM-SHA256 
-CAfile /Users/khb/ca.cert.rsa.pem -servername debian.example.com 
CONNECTED(00000003)
depth=1 C = DE, ST = Hassia, O = ACME, CN = ACME CA
verify return:1
depth=0 C = DE, ST = Hassia, O = KHB, OU = rsa, CN = debian.example.com
verify return:1
---
Certificate chain
 0 s:C = DE, ST = Hassia, O = KHB, OU = rsa, CN = debian.example.com
   i:C = DE, ST = Hassia, O = ACME, CN = ACME CA
 1 s:C = DE, ST = Hassia, O = ACME, CN = ACME CA
   i:C = DE, ST = Hassia, O = ACME, CN = ACME CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFUD
CCAzigAwIBAgICEAAwDQYJKoZIhvcNAQELBQAwPzELMAkGA1UEBhMCREUx
...
/jTQpxrZyObmcSxS3TSlw+Ixy74=
-----END CERTIFICATE-----
subject=C = DE, ST = Hassia, O = KHB, OU = rsa, CN = debian.example.com


issuer=C = DE, ST = Hassia, O = ACME, CN = ACME CA


---
Acceptable client certificate CA names
C = DE, ST = Hassia, L = Test, O = KHB, CN = debian.example.com
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: ECDSA+SHA512:RSA+SHA512:ECDSA+SHA384:RSA+SHA384:ECDSA+SHA256:RSA+SHA256:DSA+SHA256:ECDSA+SHA224:RSA+SHA224:DSA+SHA224:ECDSA+SHA1:RSA+SHA1:DSA+SHA1
Shared Requested Signature Algorithms: ECDSA+SHA512:RSA+SHA512:ECDSA+SHA384:RSA+SHA384:ECDSA+SHA256:RSA+SHA256:DSA+SHA256:ECDSA+SHA224:RSA+SHA224:DSA+SHA224:ECDSA+SHA1:RSA+SHA1:DSA+SHA1
Peer signing digest: SHA256
Peer signature type: 
RSA
Server Temp Key: DH, 1024 bits
---
SSL handshake has read 3574 bytes and written 347 bytes
Verification: OK
---
New, TLSv1.2, Cipher is DHE-
RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : DHE-RSA-AES128-GCM-SHA256
    Session-ID: 5E4E5EF298FC9D0F81B60A1E3C36A872673BA32E548CD428C936559FAD53D316
    Session-ID-ctx: 
    Master-Key: 7B04C38682E3C52DA7BDCA30CC67A78BB9AB33DA270C10217C77F7FF4D631FA1AE351660E17D0ABF38A7AC6C4407FAFB
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1582194420
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: yes
---
^C

As you can see, both cipher suites work, the server sent different server certificates in each case, automatically picked to match the cipher suite the client requested. Conversely, if you set a cert nickname to one of the certificates (oud.rsa e. g.), you can see how the other cipher stops working.

This seems to work quite well, if you just let the JVM do its thing.

Tagged , , ,

Deutsche Bank and TAN lists

So, my daughter needs a new phone. I feel really old-school with my iPhone 5SE, but whatever. She has earned money from video editing for a local business and also saved some pocket-money, so fine. She wants to spend almost 800 € that are all her own on a new phone, so be it. Turns out the phone is cheaper on Amazon than in the Apple Store, directly, even when you throw in an AppleCare protection plan, and of course I go order it online and suddenly find myself with a lot of cash, that I feel way to uncomfortable with to not bank it.

My account has been with Deutsche Bank forever for mostly historical reasons, but you know how long-term relationships go with banks, especially after stuff like a mortgage on a house happens and all that. So, between dropping my daughter off at school and running other errands, I hop into their nearest branch office to deposit the money. When I head to that one ATM that also takes deposits, there is this marketing guy chatting up another customer and I already cringe when I hear him explain how printed TAN lists are a security risk. The yarn he spins is how the frequency of burglaries is increasing and somebody could steal the list of TANs. He even has the nerve to mention that he has no idea why, but some people blame it on the influx of refugees!

Inside I keep going, damn, I don’t have time for that kind debate, when he explains how that is why they are planning to discontinue offering printed TAN lists around summer next year and people should get used to the photoTAN method. Screw you, methinks, and I do sincerely hope Deutsche Bank is not pushing photoTAN to protect us from refugees who are after our bank accounts. Or else I might have to reconsider my choice of bank. This story was bullsh!t on so many levels.

Yes, printed TANs do not solve every security issue that exists with online banking. But generally speaking, the TAN mechanism as a form of one-time-pad is one of the better ideas people have come up with. It offers a practical form of two-factor authentication where you have to have something and to know something to get access to your account. Somebody can steal your TAN list and without your online banking PIN it is useless and vice versa. The remaining security concerns that do exist largely revolve around (1) man-in-the-middle attacks and (2) a responsible use of TANs / convenience.

Traditional TANs (and iTANs) are agnostic of the kind of transaction. Neither for the user nor for the bank is there a way to ensure the TAN is actually used for the transaction the user intended it to be used for. If somebody can get between the bank and the client, he might be able to catch a TAN that was meant for a 5 € payment and use it to transfer a million to his own account (if you don’t have a set limit for online transactions.) Seriously, though, phishing attempts aside, and people clicking on stuff they should not be clicking on and not paying attention, that is a pretty hard thing to do. Having somebody present me a webpage that comes from the deutsche-bank.de domain, has a valid SSL certificate that my browser trusts, gets me through the regular PIN-based login and the whole workflow of ordering a money transfer up to the point where I have to enter a TAN, and still being able to see through the encrypted channel, is something my employer could do on hardware where he controls my browser’s proxy settings. And yes, somebody who similarly pwned my personal computer could do it. But using online banking from a piece of equipment that has been pwned, one way or another, is generally a bad idea. And we will come back to that line of thought.

The other problem with printed TAN lists is, of course, mobility. They are really not intended to be carried around at all times. If you do, the chances of them getting into the wrong hands obviously increases, a lot. As a matter of fact, traditional TANs even lent themselves to being used on the go a bit more than the current iTANs, because you could just copy three or four TANs from the list you kept stored safely at home and take them along on a trip. With iTANs that is no longer possible, because you do no know in advance which TAN you will be prompted for. On the other hand, people are getting used to doing everything mobile, and thus there is the risk of people not using TAN lists carefully enough. But that is just as true for many other forms of TAN, such as mTAN, photoTAN, or whatnot. Like, having an app on your phone to login to your account which potentially even saves your online banking PIN in a keychain, and then getting an mTAN as text message to that same phone entirely defeats the purpose of having a two-factor authentication. All somebody needs to do after that is to steal the phone. And Deutsche Bank even advertises on their webpage that, if you have both the banking app and the photoTAN app on your device, you do not need anything else. Am I the only one thinking there is something wrong, here?

I get convenience. I mean, I personally feel like convenience is the the thing that makes many people on the internet hang the noose around their own necks, but I do get it. I also get how banks want to get rid of having to print those TAN lists and keep mailing them to people. Just don’t try to sell it to me as a security feature. The one-time-pad’s security hinges on the safe channel through which the communicating parties pre-share their keys. And the sealed blackened envelope my printed TAN lists arrive in is something I as a person feel much more capable of handling securely than anything that involves electronic communication. Also the risk of them getting stolen: I don’t carry them around. I keep them tucked away somewhere, at home. And burglars just don’t break into your house and go search for your TAN list. They don’t! They don’t even steal your flat screen television anymore, these days. They want easy cash. Given that, again, I feel a lot more capable of finding a safe spot back home to store my TAN lists than of keeping my mobile devices safe.

And here we’re coming back to the idea of doing online banking from an pwned device. Seriously? After all the recently discovered vulnerabilities, from BlueBorn to KRACK to whatnot, can anybody seriously believe they have enough control over their mobile devices to ensure they are safe to be used for online banking? I may be paranoid again, but, micropayment for all I care, but access to my one important bank account? I don’t want my mobile phone to play any part in that, whatsoever.

Sure, photoTAN also works with a dedicated scanner device, and I’ll probably opt for that, when they stop offering printed TAN lists. And it will be a little safer, because the TAN will be tied to the actual transaction. But does this, in any way, protect me from the scanner being stolen after it has been activated? Of course not. If that thing gets stolen from my house, I have to call my bank in exactly the same way that I would have to, if my current TAN list gets stolen. So please, Deutsche Bank, if you want to save yourself the effort of sending me TAN lists via snail mail, just say so. Don’t try to tell me you’re protecting me from wicked refugees breaking into my house.

 

 

Tagged , ,

StrongSwan Client with Ubuntu 16.04 LTS

So, I’m a regular user of public WLAN hotspots, those of Deutsche Telekom among others. Being the paranoid digital self-defense person I am, I’ve been using a VPN service for quite some time now. I recently noticed that my PPTP client setup stopped working at hotspot locations run by Deutsche Telekom that I regularly use, when it still worked from home or some other hotspots I use. I embarked on a journey to teach my Ubuntu laptop some more VPN protocols. OpenVPN worked like a charm with just installing the obvious packages for network-manager. StrongSwan, however, didn’t cooperate quite as easily, due to Ubuntu 16.04 having packages in its repository which are known to not work with the version of network-manager also in that version.

OK, use the source, Luke …

But rather than compile from source tarball and clutter my system with stuff, I found the repositories for zesty have the versions I need. So, I decided to backport that:

  1. Edit /etc/apt/sources.list
    1. uncomment all deb-src lines and insert one line: deb-src http://de.archive.ubuntu.com/ubuntu/ zesty main restricted universe multiverse
  2. apt-get update
  3. apt-get install build-essential
  4. mkdir strongswan
  5. cd strongswan
  6. apt-get build-dep strongswan
  7. apt-get source strongswan
  8. export DEB_BUILD_OPTIONS=nocheck
  9. dpkg-buildpackage -us -uc
  10. dpkg -i strongswan-nm_5.5.1-1ubuntu3_amd64.deb libstrongswan_5.5.1-1ubuntu3_amd64.deb strongswan-libcharon_5.5.1-1ubuntu3_amd64.deb
  11. cd ..
  12. mkdir nm-strongswan
  13. apt-get build-dep network-manager-strongswan
  14. apt-get source network-manager-strongswan
  15. dpkg-buildpackage -us -uc
  16. dpkg -i network-manager-strongswan_1.4.1-1_amd64.deb

Then configure as per wiki page.

Now, I only need to find out how to trust the VPN provider’s certificate when their IKEv2 configuration howtos all seem to rely on turning certificate verification off.

Tagged , , , ,