Based on the following sencryption protocols, what's the supported one by Asterisk?
RC4
RC2
DES
3DES
Are there other encryption protocols suppoorted by asterisk?
Are there an asterisk command to know the supported encryption protocols?
With regards to SIP, Asterisk (via chan_sip) supports encryption of both the signalling and the media. Arheops comment that Asterisk 1.8 doesn't support encryption is incorrect; this is true in Asterisk 1.8 and all later versions. For more information, see the Secure Calling section on the Asterisk wiki.
Signalling is encrypted using OpenSSL (yes, the one with the vulnerability. Upgrade if you haven't). It defers encryption of the SIP signalling to OpenSSL. Which cipher is used is dependent on the version of OpenSSL you have installed, as well as what you configure in sip.conf, via the tlscipher option.
;tlscipher=<SSL cipher string>
; A string specifying which SSL ciphers to use or not use
; A list of valid SSL cipher strings can be found at:
; http://www.openssl.org/docs/apps/ciphers.html#CIPHER_STRINGS
;
Asterisk supports encryption of the media in one of two ways. The first, supported in Asterisk 1.8 and later, is SDES-SRTP, via the libsrtp library. libsrtp uses AES as the default cipher.
As SDES-SRTP has to exchange keys in plain text in the signalling, another method of encrypting the media is available in Asterisk 11 and later, DTLS-SRTP. This uses OpenSSL's DTLS capabilities (available in more recent versions) to exchange the keys between the participants in the encrypted media stream. Note that this is the mechanism mandated by WebRTC (whereas SDES-SRTP got slapped down with a "SHOULD NOT" be implemented).
On a final note, in Asterisk 12, the new SIP stack (based on PJSIP), also supports all of these various encryption mechanisms.
Related
I have been working to create an RTP/RTCP client and server implementation as a project. I have hit a block when it comes to parsing incoming packets because I am having trouble understanding the encryption method. I have read RFC 3550 several times. Section 9 explains confidentiality and security. I've read about DES-CBC mode here.
Observations I've deduced about encryption
RTP/RTCP packets are encrypted as a unit, meaning ALL bytes are encrypted
Encrypted RTCP packets are prefixed with a 32-bit random number
Encrypted RTP packets are randomized by the timestamp and sequence number
DES-CBC is the default mode
DES-CBC mode requires a 64-bit key
DES-CBC mode requires a 64-bit initialization vector (IV)
DES-CBC has a block size of 64 bits
What I'm confused about:
DES-CBC states that it uses the "Privacy Enhancement for Internet Electronic Mail" (PEM) protocol, but the RTP RFC makes no mention of this. In addition, the encryption diagrams do not include any PEM headers or elements.
Diagram
UDP packet UDP packet
----------------------------- ------------------------------
[random][RR][SDES #CNAME ...] [SR #senderinfo #site1 #site2]
----------------------------- ------------------------------
encrypted not encrypted
So my questions are:
Where does the key come from or what header elements make up the key?
What is the initialization vector for RTP/RTCP?
How do I parse an encrypted packet vs an unencrypted one?
Does RTP/RTCP use the PEM protocol? If so, how?
DES-CBC is a way for encrypting data and it can be used for all different protocols that need it's data to be encrypted.
Where does the key come from or what header elements make up the key?
Encryption keys are generated during connection initialization(at connect time) and can be generated using different ways but generally using Public key cryptography(ex: RSA and DH) and using certificates to prevent MITM attacks which is where the PEM standards are used.
What is the initialization vector for RTP/RTCP?
The IV(initialization vector) is randomly generated number that will be used to ensure that same plaintext will not be encrypted to same ciphertext if using same key (That's why it's Random).
How do I parse an encrypted packet vs an unencrypted one?
For encrypted packets you decrypt first using key(SECRET) you got at connection time then use IV which is sent with data packets(NOT secret) to reverse encryption process. For unencrypted packets you just parse the data since there is no KEY and IV data is just plaintext.
Does RTP/RTCP use the PEM protocol? If so, how?
PEM is not protocol in the sense as network protocols such SSH. This definition I think is accurate enough from wikipedia
Privacy-Enhanced Mail (PEM) is a de facto file format for storing and sending cryptographic keys, certificates, and other data, based on a set of 1993 IETF standards defining "privacy-enhanced mail.
so if your client is using encryption there is a very big chance that it will be using PEM standards for symmetric key initialization.
NOTE: timestamp and sequence number are different from IV these fields are RTP header fields which can serve a similar purpose but they are different from CBC mode IV.
According to https://cloud.google.com/iot/docs/how-tos/mqtt-bridge#downloading_mqtt_server_certificates TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 using P-256 is recommended for mqtt.2030.ltsapis.goog
The IoT module that I'm using (Quectel M66) supports only the following cipher suites.
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
Is it possible to connect to mqtt.2030.ltsapis.goog using one of the above cipher suites?
Thanks
Unfortunately, it will not be possible.
The long term MQTT domain is intended to aid in using a TLS configuration for a long period of time. As such, the TLS features listed in the documentation could be seen as "minimum standard needed" to ensure security.
You can read more about Google's minimum standards for TLS clients here
Do note that you can test the following points:
TLS 1.2 must be supported.
A Server Name Indication (SNI) extension must be included in the handshake and must contain the domain that's being connected to.
The cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 must be supported with P-256 and uncompressed points.
In this link https://cert-test.sandbox.google.com/
It is unlikely support will be added to those older cipher suites, since it could potentially lead to botnets and other security issues over time. You can also verify the security of cipher suites in this link which is updated regularly.
The recommendation would be to look for devices that support TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 using P-256 and uncompressed points for the cipher suite, which will have a higher likelihood of working uninterrupted for a few years.
RTSP 1.0's RFC2326 uses RFC2617 for WWW Authentication, which is the same used for HTTP authentication. This 2617 is old and only covers MD5. I know that RTSP 2.0 is out but I'm working on 1.0. Lots of IP cameras still implement 1.0 only.
I guess some cameras might use SHA1. SHA2 might be too new, I don't know if they use but it's possible.
Which RFC should I read to bring SHA1 and possibly SHA2 to RTSP 1.0? Should I just use the latest WWW Authentication RFC, if such exists?
Actually, RFC 2326 predates RFC 2617, so pedantically speaking, it used an even older version of HTTP auth.
It appears you are interested in "Digest" authentication. The relevant spec for that nowadays is RFC 7616. It's supposed to be backwards-compatible, so I would recommend it as the definitive source.
Just be aware of the changes compared to older specs, which the devices you want to talk to might not implement: https://www.rfc-editor.org/rfc/rfc7616#appendix-A
Does someone now with key size (128-bit?) is used by GLib in GSocketConnection/GTlsConnection? Is this fix implemented or changeable?
In GLib, you are effectively negotiating a TLS (Transport Layer Security) session key/cipher.
Therefore this will depend on the connection partners preferences and supported cipher suite.
Cipher suites will be dependent on the version of TLS used too.
More information on TLS cipher suites here.
The TLS implementation in GLib actually just uses either GnuTLS or OpenSSL, so the key size is handled by them. GLib does not override their defaults or decisions.
During an SSL/TLS handshake, the client sends up a list of supported cipher suites and the server selects which one to use for the conversation. Windows has a prioritized list of cipher suites (configurable via the registry) and will select the first suite in that list that is supported by the client. Once a list of acceptable ciphers is created using the cipher suite flags, what algorithm does OpenSSL use to select the cipher suite when it's acting as a server? I could not find the answer in the OpenSSL documentation.
The list of cipher suites sent by the client is ordered; the first suite in the list is the one most preferred by the client. Normally, OpenSSL, as a server, honors the client preference: it selects the suite most preferred by the client among the list of suites that both the client and server support.
Since OpenSSL-0.9.7 (released at the end of 2002), OpenSSL has a programmatic flag called SSL_OP_CIPHER_SERVER_PREFERENCE which enforces the server preferences: the list of cipher suites supported by the server is also ordered by preference, and the server selects the suite that the server itself most prefers among those that both the client and server support. This flag is documented in the ssl.h include file.
With the command-line "s_server" command, the "-serverpref" option is used to activate the SSL_OP_CIPHER_SERVER_PREFERENCE flag.
Have a look at this manpage.
The cipherlist command converts OpenSSL cipher lists into ordered SSL
cipher preference lists. It can be used as a test tool to determine the
appropriate cipherlist.