skip to main content.

posts for 2015. (page 1.)

two weeks ago, we tried out the bernina express panoramic train from chur to tirano, and afterwards the bernina express bus to lugano.

the beginning of the trip, from chur to st. moritz, is similar to the last part of the glacier express train ride (starting in zermatt), following the albula line, and then follows the bernina line via the bernina pass to italy, peaking at 2253 meters above sea level.

we were lucky and the weather was (once again) quite good – which was quite some luck: on the day before, where we originally wanted to go but didn’t got a reservation, it was raining like crazy. the panorama carriages were once again nice, though taking photos is still quite a challenge thanks to the reflections which are almost always there. but hey, we were there to enjoy the views, and not to make great photos. (that’s for some other time. there’s a lot of beauty out there, for example the morteratsch glacier which we could watch while driving by.)

anyway. the second main part of the trip, the express bus from tirano to lugano, wasn’t as good as we hoped – i always feel kind of squeezed in a bus and am looking forward to leave it :-). the views were nice, but the next time i’d still skip that part.

a couple of weeks ago, we visited oslo. yet another time. the weather was suprisingly good, we had a lot of sun but it wasn’t too hot.

we spend some time in the city…

… did some island hopping, walking on both lindøya and hovedøya, and inspecting in particular hovedøya abbey, …

… visisted the norwegian maritime museum on bygdøy, …

… lake sognsvann, …

… and the botanical garden tøyenhagen.

this weekend, i spend a bit of time pimping my nginx tls/ssl configuration for https. my goal was to achieve much better on the ssl labs ssl server test. well, my top score will never exceed T due to my self-signed certificate, but fortunately it also shows the top score ignoring trust issues. and there, i finally got an A!

of course, there’s always a downside. since certain older clients are incapable of dealing with modern ciphers and protocols (like tls 1.2), you either have to support cipher/hash/… combinations which aren’t exactly secure, or drop support for these clients. if you want a good score from the ssl server test, you have to drop support for some clients.

in my case (and after doing quite some experiments), i decided to drop support for:

  • android 2.3.7 (and similar): no 256 bit ciphers, and no support of tls 1.1 or higher;
  • internet explorer 6 and 8 under windows xp: not even tls 1.0 (ie 6), or no tls 1.1 or higher (ie 8), and no 256 bit ciphers;
  • all kind of javas (java 6u45, 7u25, 8b132): while java 8 finally supports tls 1.2 (the others only up to tls 1.0), there are no 256 bit ciphers.

all other clients tested on the ssl server test have no problem connecting with my config, and all result in 256 bit ciphers with forward secrecy.

the total result is 100% for key exchange and ciphers, and 95% for protocol support (i guess supporting tls 1.0 is the problem, but that’s needed for quite some clients). you can see the result here. i probably would have gotten 100% for the certificate, too, if it would not have been self-signed (by my own ca), but by something “trustworthy”.

to achieve this, i used 4096 bit rsa keys and a 4096 bit dh setting. generating the server certificate (with the rsa keys) is pretty standard, but what i haven’t seen very often is the diffie-hellman key exchange parameters generation (in fact, i’ve first seen it here):

1openssl genpkey -genparam -algorithm DH -out dhparam.pem -pkeyopt dh_paramgen_prime_len:4096

this generates a diffie-hellman setup with a 4096 bit prime. a smaller prime is fine for most scenarios, but if you’re paranoid enough, 4096 bits is a good start :-) note that the prime bitlength has a direct impact on the server (and client) load when a new tls/ssl connection with forward secrecy is initiated. the longer the prime is, the slower this will be. (the handshake is superlinear in the number of bits, and probably closer to quadratic than to the complexity-theoretic optimum of O(n1+ɛ) for every ɛ > 0.) for more modern clients, though, an elliptic curve based setting will be used, which is much more efficient since it uses way smaller finite fields.

anyway, here’s the config:

1ssl_session_cache shared:SSL:5m;
2ssl_session_timeout  5m;
3
4ssl_dhparam /etc/nginx/dhparam.pem;
5
6ssl_protocols TLSv1.2 TLSv1;
7ssl_prefer_server_ciphers on;
8ssl_ciphers "-ALL !ADH !aNULL !EXP !EXPORT40 !EXPORT56 !RC4 !3DES !eNULL !NULL !DES !MD5 !LOW ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES256-SHA384 ECDHE-RSA-AES256-SHA384 DHE-RSA-AES256-SHA256 ECDHE-ECDSA-AES256-SHA ECDHE-RSA-AES256-SHA DHE-RSA-AES256-SHA";

this leads to the following list of ciphers:

1prio  ciphersuite                  protocols      pfs_keysize
21     ECDHE-RSA-AES256-GCM-SHA384  TLSv1.2        ECDH,P-256,256bits
32     DHE-RSA-AES256-GCM-SHA384    TLSv1.2        DH,4096bits
43     ECDHE-RSA-AES256-SHA384      TLSv1.2        ECDH,P-256,256bits
54     DHE-RSA-AES256-SHA256        TLSv1.2        DH,4096bits
65     ECDHE-RSA-AES256-SHA         TLSv1,TLSv1.2  ECDH,P-256,256bits
76     DHE-RSA-AES256-SHA           TLSv1,TLSv1.2  DH,4096bits

(courtsey to cipherscan.)

i’d like to also use http strict transport security, but that won’t work well if you have a self-signed certificate, thanks to its specifications (see point #2 here). also, ocsp stapling makes no sense with a self-signed certificate and without a proper ca. finally, i’d like to use public key pinning in the future, but that’s rather experimental at the moment.

one thing i’m missing quite badly is proper elliptic curve support. with that i mean good (non-nist) curves, like the ones listed as “safe” on this page, especially the higher security ones (like curve41417, ed448-goldilocks, m-511 and m-521). unfortunately, i’m afraid it will take a long time until we can use them with tls, not only because they first have to get into a standard, but then the standard has to be implemented by clients and enough clients must be able to use it. consider for example tls 1.2, which was defined in august 2008. while finally all current browsers support it (that hasn’t been the case a couple of years ago, similar to tls 1.1 which has been around since april 2006), it took quite some time, and there are still a lot of older browsers out there which don’t support it. just consider many smartphones produced in the last years with android 4.3 an older (which includes my fairphone), which have only tls 1.0 support. or safari 6 included with osx 10.8, openssl 0.9.8, internet explorer mobile on windows phone 8.0, internet explorer up to version 10, and quite some search machine bots.

note that in my above config, the elliptic curve used for diffie-hellman is p-256, a nist curve. it’s one of these nsa generated curves, and it’s not exactly optimal (search for p-256 here). unfortunately, with current tls, there’s not much you can do about this… too bad.

posted in: computer
tags:
places:

last night, it snowed again. so today, after shoveling more snow, we built a snowman. our cats had some fun, too:

the last snow is long gone. but a week ago, it started snowing again. last sunday, we went on a nice walk from hadlikon to hinwil. the weather was really beautiful!

as soon as we arrived home, it changed a bit, though: the sky turned grey. so after cleaning the stairs from the snow, we went back inside to join our cats in the warmth:

somewhen after christmas, it suddenly started snowing in switzerland. so when we returned from lappland, we could enjoy quite a lot of snow!

we weren’t the only ones enjoying it: the cats also like it. well, at least the young ones. some even jump into deep snow to catch a snowball! (sorry, no photos of that…)

too bad most of the snow has already melted again…