Android: Der Beitrag stellt die Vorbereitung des Testgeräts sowie Werkzeuge (Frida, Magisk) zur Analyse des Datensendeverhaltens von Apps vor. Reinschauen! ✌️ 👇
Für Leute, die eigene Server betreiben und mal Klarheit bei der vorliegenden #TLS#SSL#encryption benötigen, können es hiermit testen.
testssl.sh is a free command line tool which checks a server's service on any port for the support of TLS/SSL #ciphers, protocols as well as recent cryptographic flaws and more.
Je viens juste de me rendre compte que #TCPFastOpen n'était pas activé sur mes 2 serveurs faisant autorité acceptant les requêtes via #TLS (chiffrement opportuniste, les certificats sont auto-signés — mais vérifiables via #DANE/TLS). J'étais donc en (léger) froid avec la section 4.1 du RFC 9210 (aka BCP 235) :
Getting close to a full green #Bunny running fully on @reactphp. There is one #TLS/#SSL test left to resolve before this will become the base for 0.6.x. #php#rabbitmq#amqp
NIST has a practice guide for "Addressing Visibility Challenges with #TLS 1.3 within the Enterprise", discussing "key-management" (control/collect/keep all encryption keys), #middleboxes, and, you know, not encrypting data ("alternative network security protocols where forward secrecy is optional or not supported").
If you have opinions, the public comment period is now open until 2024-04-01...
Reading a review in an older edition of the #TLS - deliveries here are not very reliable - and I came across a sentence in one review which both sums up the English attitude, in all its arrogance, and sets a certain expected age for readers:
"...this didn't prevent his winning the Military Cross in the war."
You have to be of a certain age and disposition to see how this works.
This is the first post of a series where we go through the performance work we did in rustls, a modern TLS library in Rust. Today we tame the borrow checker using mem::take.
A while ago I mentioned I use Android-10 with the built in SIP stack and that the Google stack was pretty buggy and I had to fix it simply to get it to function without disconnecting all the time. Since then I’ve upported my fixes to Android-11 (the jejb-11 branch in the repositories) by using LineageOS-19.1. However, another major deficiency in the Google SIP stack is its complete lack of security: both the SIP signalling and the media streams are all unencrypted meaning they can be intercepted and tapped by pretty much anyone in the network path running tcpdump. Why this is so, particularly for a company that keeps touting its security credentials is anyone’s guess. I personally suspect they added SIP in Android-4 with a view to basing Google Voice on it, decided later that proprietary VoIP protocols was the way to go but got stuck with people actually using the SIP stack for other calling services so they couldn’t rip it out and instead simply neglected it hoping it would die quietly due to lack of features and updates.
This blog post is a guide to how I took the fully unsecured Google SIP stack and added security to it. It also gives a brief overview of some of the security protocols you need to understand to get secure VoIP working.
What is SIP
What I’m calling SIP (but really a VoIP system using SIP) is a protocol consisting of several pieces. SIP (Session Initiation Protocol), RFC 3261, is really only one piece: it is the “signalling” layer meaning that call initiation, response and parameters are all communicated this way. However, simple SIP isn’t enough for a complete VoIP stack; once a call moves to in progress, there must be an agreement on where the media streams are and how they’re encoded. This piece is called a SDP (Session Description Protocol) agreement and is usually negotiated in the body of the SIP INVITE and response messages and finally once agreement is reached, the actual media stream for call audio goes over a different protocol called RTP (Real-time Transport Protocol).
How Google did SIP
The trick to adding protocols fast is to take them from someone else (if you’re open source, this is encouraged) so google actually chose the NIST-SIP java stack (which later became the JAIN-SIP stack) as the basis for SIP in android. However, that only covered signalling and they had to plumb it in to the android Phone model. One essential glue piece is <a href="https://android.googlesource.com/platform/frameworks/opt/net/voip/">frameworks/opt/net/voip</a> which supplies the SDP negotiating layer and interfaces the network codec to the phone audio. This isn’t quite enough because the telephony service and the Dialer also need to be involved to do the account setup and call routing. It always interested me that SIP was essentially special cased inside these services and apps instead of being a plug in, but that’s due to the fact that some of the classes that need extending to add phone protocols are internal only; presumably so only manufacturers can add phone features.
Securing SIP
This is pretty easy following the time honoured path of sending messages over TLS instead of in the clear simply by using a TLS wrappering technique of secure sockets and, indeed, this is how RFC 3261 says to do it. However, even this minor re-engineering proved unnecessary because the nist-sip stack was already TLS capable, it simply wasn’t allowed to be activated that way by the configuration options Google presented. A simple 10 line patch in a couple of repositories (<a href="https://github.com/jejb/android_external_nist-sip/commit/fc1a69d1df6ed784b3913404f653b83cf49063b1">external/nist_sip</a>, <a href="https://github.com/jejb/android_packages_services_Telephony/commit/a6c4f6e9d876a9a3b9a5bb051e2656ec18ae3c10">packages/services/Telephony</a> and <a href="https://github.com/jejb/android_frameworks_opt_net_voip/commit/1800c4bfcba093f4a834fb0b23f5b8d72b089b3c">frameworks/opt/net/voip</a>) fixed this and the SIP stack messaging was secured leaving only the voice stream insecure.
SDP
As I said above, the google frameworks/opt/net/voip does all the SDP negotiation. This isn’t actually part of SIP. The SDP negotiation is conducted over SIP messages (which means it’s secured thanks to the above) but how this should be done isn’t part of the SIP RFC. Instead SDP has its own RFC 4566 which is what the class follows (mainly for codec and port negotiation). You’d think that if it’s already secured by SIP, there’s no additional problem, but, unfortunately, using SRTP as the audio stream requires the exchange of additional security parameters which added to SDP by RFC 4568. To incorporate this into the Google SIP stack, it has to be integrated into the voip class. The essential additions in this RFC are a separate media description protocol (RTP/SAVP) for the secure stream and the addition of a set of tagged a=crypto: lines for key negotiation.
As will be a common theme: not all of RFC 4568 has to be implemented to get a secure RTP stream. It goes into great detail about key lifetime and master key indexes, neither of which are used by the asterisk SIP stack (which is the one my phone communicates with) so they’re not implemented. Briefly, it is best practice in TLS to rekey the transport periodically, so part of key negotiation should be key lifetime (actually, this isn’t as important to SRTP as it is to TLS, see below, which is why asterisk ignores it) and the people writing the spec thought it would be great to have a set of keys to choose from instead of just a single one (The Master Key Identifier) but realistically that simply adds a load of complexity for not much security benefit and, again, is ignored by asterisk which uses a single key.
In the end, it was a case of adding a new class for parsing the a=crypto: lines of SDP and doing a loop in the audio protocol for RTP/SAVP if TLS were set as the transport. This ended up being a ~400 line patch.
Secure RTP
RTP itself is governed by RFC 3550 which actually contains two separate stream descriptions: the actual media over RTP and a control protocol over RTCP. RTCP is mostly used for multi-party and video calls (where you want reports on reception quality to up/downshift the video resolution) and really serves no purpose for audio, so it isn’t implemented in the Google SIP stack (and isn’t really used by asterisk for audio only either).
When it comes to securing RTP (and RTCP) you’d think the time honoured mechanism (using secure sockets) would have applied although, since RTP is transmitted over UDP, one would have to use DTLS instead of TLS. Apparently the IETF did consider this, but elected to define a new protocol instead (or actually two: SRTP and SRTCP) in RFC 3711. One of the problems with this new protocol is that it also defines a new ciphersuite (AES_CM_…) which isn’t found in any of the standard SSL implementations. Although the AES_CM ciphers are very similar in operation to the AES_GCM ciphers of TLS (Indeed AES_GCM was adopted for SRTP in a later RFC 7714) they were never incorporated into the TLS ciphersuite definition.
So now there are two problems: adding code for the new protocol and performing the new encyrption/decryption scheme. Fortunately, there already exists a library (<a href="https://github.com/cisco/libsrtp/">libsrtp</a>) that can do this and even more fortunately it’s shipped in android (<a href="https://android.googlesource.com/platform/external/libsrtp2/">external/libsrtp2</a>) although it looks to be one of those throwaway additions where the library hasn’t really been updated since it was added (for cuttlefish gcastv2) in 2019 and so is still at a pre 2.3.0 version (I did check and there doesn’t look to be any essential bug fixes missing vs upstream, so it seems usable as is).
One of the really great things about libsrtp is that it has srtp_protect and srtp_unprotect functions which transform SRTP to RTP and vice versa, so it’s easily possible to layer this library directly into an existing RTP implementation. When doing this you have to remember that the encryption also includes authentication, so the size of the packet expands which is why the initial allocation size of the buffers has to be increased. One of the not so great things is that it implements all its own crypto primitives including AES and SHA1 (which most cryptographers think is always a bad idea) but on the plus side, it’s the same library asterisk uses so how much of a real problem could this be …
Following the simple layering approach, I constructed a patch to do the RTP<->SRTP transform in the JNI code if a key is passed in, so now everything just works and setting asterisk to SRTP only confirms the phone is able to send and receive encrypted audio streams. This ends up being a ~140 line patch.
So where does DTLS come in?
Anyone spending any time at all looking at protocols which use RTP, like webRTC, sees RTP and DTLS always mentioned in the same breath. Even asterisk has support for DTLS, so why is this? The answer is that if you use RTP outside the SIP framework, you still need a way of agreeing on the keys using SDP. That key agreement must be protected (and can’t go over RTCP because that would cause a chicken and egg problem) so implementations like webRTC use DTLS to exchange the initial SDP offer and answer negotiation. This is actually referred to as DTLS-SRTP even though it’s an initial DTLS handshake followed by SRTP (with no further DTLS in sight). However, this DTLS handshake is completely unnecessary for SIP, since the SDP handshake can be done over TLS protected SIP messaging instead (although I’ve yet to find anyone who can convincingly explain why this initial handshake has to go over DTLS and not TLS like SIP … I suspect it has something to do with wanting the protocol to be all UDP and go over the same initial port).
Conclusion
This whole exercise ended up producing less than 1000 lines in patches and taking a couple of days over Christmas to complete. That’s actually much simpler and way less time than I expected (given the complexity in the RFCs involved), which is why I didn’t look at doing this until now. I suppose the next thing I need to look at is reinserting the SIP stack into Android-12, but I’ll save that for when Android-11 falls out of support.
Are there already elegant solutions for distributing Let's Encrypt certificates to multiple hosts?
Of course, you can have each host request certificates individually, but then you run into ACME API limits at Let's Encrypt relatively quickly, depending on the number of hosts and simultaneous accesses.
We strongly warn against the currently proposed trilogue agreement, as it fails to properly respect the right to privacy of citizens and secure online communication; without establishing proper safeguards as outlined above, it instead substantially increases the potential for harm.
TIL you can show only the SAN list of a cert via openssl: echo| openssl s_client -connect www.bbc.co.uk:443 -showcerts 2>/dev/null | openssl x509 -noout -ext "subjectAltName"
I'd always parsed that out manually..🤦🏻♂️. #OpenSSL#TLS#InfoSec#DevOps#SysEng
I had to install #Git on a #Windows machine today and OH MY GOD I forgot how complex of a set up process it is. I went through it again just to count the unbelieveable number of steps it took:
License agreement.
Which components to install (includes proper nouns like "Git Bash", "Git LFS", and "Scalar"). Notably does not enable automatic updates by default.
Default editor for Git (doesn't include #Emacs as an option).