Closed vazir closed 6 years ago
@kYroL01 can you please assist ?
Hi @vazir . Two main questions:
[DEBUG] protocol_tcp.c:201 KEY in proto_tcp = 9766 [DEBUG] protocol_tcp.c:270 TLS packet found
), so are u sure that a complete handshake session is captured ? If not, it's impossible for the dissector to decrypt the traffic.@kYroL01 - I would be happy to check it - but there is nothing else in the captagent log.
1 - Can you elaborate how to either check it or maybe i just regenerate keys differently.
Please see the cert dump if it helps
# openssl rsa -in agent.key -check
RSA key ok
# openssl x509 -in agent.pem -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 13740297812824547223 (0xbeaf580fc17bdf97)
Signature Algorithm: sha1WithRSAEncryption
Issuer: CN=(ipcut), O=(cut)
Validity
Not Before: Jan 24 16:38:01 2018 GMT
Not After : Jan 23 16:38:01 2024 GMT
Subject: CN=(ip-cut), O=(cut)
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:a8:cd:2e:d6:7d:74:36:07:b2:43:2f:29:a3:10:
c4:28:f3:40:7c:dd:83:79:7d:1e:e6:1a:8a:63:c8:
4e:a0:36:e3:2c:11:48:72:96:7f:1f:0b:57:cf:db:
61:b3:ab:8c:7d:23:c2:7e:47:71:c4:78:9f:35:74:
a9:d8:e2:f8:83:a2:06:f1:b1:4b:22:96:2e:73:d3:
ae:9d:07:88:df:0b:87:53:0c:de:54:5f:43:34:2f:
45:81:94:8d:58:e4:18:ac:8a:5c:d7:c3:75:f4:28:
6e:9c:79:bf:af:67:5d:c2:c2:22:00:55:5f:01:33:
38:94:a4:5a:9e:e6:05:40:91:3a:56:9a:61:13:85:
85:3a:f2:31:70:de:4c:ca:f1:18:18:df:58:1b:f6:
93:3d:c1:f9:90:4e:69:a8:10:30:18:2c:0d:d9:bd:
66:b0:1a:c8:d3:26:19:37:96:df:1a:17:c9:0b:bb:
0c:4c:50:45:db:e2:8f:98:7a:8b:f9:1d:91:af:7b:
33:af:73:b6:fc:3a:0d:bc:b3:b3:63:51:7a:82:02:
69:63:ea:40:af:ff:5d:85:57:32:13:94:93:32:54:
33:79:62:93:e8:67:72:a6:8e:89:ab:c4:b9:73:0d:
3e:4d:38:ea:4a:a1:f9:66:67:4c:89:29:20:02:e9:
cf:59
Exponent: 65537 (0x10001)
X509v3 extensions:
Netscape Comment:
FS Server Cert
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
C4:17:FA:CA:4F:F8:99:69:94:11:C7:98:6D:15:53:9F:5A:48:D7:45
X509v3 Authority Key Identifier:
keyid:09:82:F1:4D:B7:E1:90:D5:18:6C:6C:FA:7E:BB:1C:61:C2:BE:96:E3
DirName:/CN=(ip-cut)/O=(cut)
serial:BA:4D:0F:5C:D8:4B:99:CA
X509v3 Subject Alternative Name:
DNS:(dns-cut)
Netscape Cert Type:
SSL Server
X509v3 Extended Key Usage:
TLS Web Server Authentication
Signature Algorithm: sha1WithRSAEncryption
5c:56:47:35:bb:3e:e8:4c:d4:f0:2f:5b:5c:4e:a3:52:1b:36:
1a:5c:a4:4a:1a:39:78:18:27:8c:a3:fd:5e:52:09:05:d3:e7:
25:be:d5:07:02:22:dd:84:c1:ee:93:c6:eb:e5:b2:0c:91:7e:
1a:e8:55:cb:41:39:f5:96:29:41:20:0d:d3:1b:4a:ce:b4:fc:
c8:c4:2b:80:81:fb:26:41:8f:39:00:47:ab:29:64:60:11:74:
62:26:fd:b1:e4:bb:93:d6:b8:4a:87:97:7c:66:10:8a:5c:39:
6a:3b:14:38:47:56:22:b5:18:05:29:d6:24:0b:0c:36:84:70:
7c:a9:d3:c1:09:52:21:d0:45:6a:6d:0b:8b:fb:a4:f1:b7:ad:
bb:29:23:c5:f1:8f:cf:36:61:4a:b1:ed:df:f4:21:a3:b7:51:
78:78:12:fb:ca:08:e5:a4:48:fd:0c:11:a3:10:08:f1:81:ff:
f6:d1:74:2d:43:24:6b:56:ef:30:61:8b:1b:a3:ee:4a:c4:63:
39:f1:4a:59:5f:d0:a4:a2:9e:e9:4f:ba:53:ae:62:b1:84:aa:
ce:59:02:2f:e4:cb:b6:9d:06:e9:9a:de:86:ed:77:93:3e:af:
11:31:22:c6:7c:53:40:85:aa:16:c9:39:6d:9b:8c:a1:14:91:
0d:72:4d:6c
@vazir can you please first start the captagent and only after make registrations and make a call. As @kYroL01 already said, the captagent have to see TLS handshake before starting traffic decryption.
@adubovikov - i do exactly as you said. First start captagent. and only than i make a call. I will restart FS and app too to make all clean.
Aha. So when i do restart everything, log changed.
[DEBUG] captagent.c:316 The Captagent is ready[DEBUG] socket_pcap.c:764 Link offset interface type [113] [113] [16]
[DEBUG] protocol_tcp.c:201 KEY in proto_tcp = 9766
[ERR] protocol_tcp.c:252 INVALID TLS/SSL packet
[ERR] protocol_sip.c:132 Error parsing TLS!!!!
[DEBUG] protocol_tcp.c:201 KEY in proto_tcp = 5028
[DEBUG] parser_tls.c:324 KEY CKE flow = 5028
[ERR] protocol_tcp.c:252 INVALID TLS/SSL packet
[ERR] protocol_sip.c:132 Error parsing TLS!!!!
[DEBUG] protocol_tcp.c:201 KEY in proto_tcp = 5028
Invalid Chipher Suite. No DHE/EDH availlable for decription
[ERR] protocol_tcp.c:252 INVALID TLS/SSL packet
[ERR] protocol_sip.c:132 Error parsing TLS!!!!
[DEBUG] protocol_tcp.c:201 KEY in proto_tcp = 5028
error on RSA_private_decrypt
Private Decrypt failed for PreMaster Secret
[ERR] protocol_tcp.c:241 Error on decription packet
[ERR] protocol_sip.c:132 Error parsing TLS!!!!
@vazir mmmm... Invalid Chipher Suite. No DHE/EDH availlable for decription
.
This is not good...
It should be a great thing if you give us a pcap with that traffic, to understand better the encryption.
I suspect that is DH
Sure, i will capture now
where do i send it? I can attach keys too.
As u prefer. You can send privately to mail if u prefer ( fci1908@gmail.com ). Yes please, attach the key, thanks
Sent to the email
I'll let u know asap ! Thanks
Thank you @kYroL01 !
not sure how it does influence on the TLS exchange in meaning of using the DH, but here is the my FS (standard) ciphers setting.
<X-PRE-PROCESS cmd="set" data="sip_tls_ciphers=ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH"/>
@vazir DH exchange keys over public session, therefore there is no way to decode such TLS traffic. I.e. Telegraf, Whatsapp based on DH exchange.
https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
@vazir if the standard ciphers is DH, captagent TLS cannot decrypt it. Anyway, nobody could decrypt it (read this to better understand). If you can change the cipher suite and try again could be nice.
Btw the pcap you sent me is only application data traffic. To create a session for the encryption, the TLS dissector needs an entire handshake session (start from the ClientHello message): https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.1.0/com.ibm.mq.doc/sy10660_.htm
So, if the behaviour is this, we cannot help you. I close the issue. Re-open if necessary
captagent support TLS_RSA_WITH_AES_256_GCM_SHA384 cipher
@kYroL01 - i have done the new PCAP - would appreciate very much if you can take a look. This one looks like has the key exchange part. Sent to your email
@vazir Nothing to do.
I analyzed the Server hello packet and the cipher suite shared between client and server is DH:
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
.
But in that case can you give any hint how to do it without DH? I mean how do i make it captagent compatible
The choice of RSA or DH is made by the server part, not by the client. The only thing is that the server gives the possibility to choice the encryption method.
I see. Than its necessary now to find out how to make FS to blacklist DH... :) Thank you very much for your assitance!
@vazir You're welcome!
@vazir https://freeswitch.org/confluence/display/FREESWITCH/Packet+Capture
after some experimentation with various tools, I come out with a little shell tool that maybe can be useful to you too.
It can only work with non-forward secrecy ciphers, obviously, and only if is started before the client do the initial TLS handshake (eg, just restart the client). Forward secrecy cannot be decrypted after fact, so don't waste effort.
An example of ciphers that can be decrypted are the "AES256-SHA" openssl cipher group. In FreeSWITCH, edit vars.xml and put
<X-PRE-PROCESS cmd="set" data="sip_tls_ciphers=AES256-SHA"/>
You can use ssldump to check what cipher is used by serverhello.
@vazir did it solve your problem, or any advice could be helpful? I'm facing a Cipher problem as well.
hi. solved by different way :) we migrated from sip to own proto for client connections, so we do not need SIP for customers anymore. Speaking of the sip capture problem, it was not solved, FS completely ignored my bugreport.
пт, 11 янв. 2019 г., 10:40 rexlin727 notifications@github.com:
@vazir https://github.com/vazir did it solve your problem, or any advice could be helpful? I'm facing a Cipher problem as well.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sipcapture/captagent/issues/166#issuecomment-453411732, or mute the thread https://github.com/notifications/unsubscribe-auth/AA4JedZTCxdYF1fIYnxbIpe72kgLHcNrks5vCD_sgaJpZM4RtNF1 .
Hi! Trying to capture SIP TLS . I can see this in the logs. But nothing is sent to the homer. When it is a plain SIP - there is message dump, and it is sent to homer just OK. (issue following the https://github.com/sipcapture/homer/issues/264 )
Current config protocol_tcp.xml
the key is in the regular format:
Freeswitch use it as agent.pem (together with cert)
Please let me know If any extra info is required. Thank you in advance Anton.