| SSL Tunnel requests for MMS download |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ |
◄ ► |
| Author | Message | |||
| Robert Barretto Frequent Contributor Username: Barretto Post Number: 69 Registered: 09-2019 |
Hi guys, I'm seeing some mobiles that are having problems downloading an MMS from the MMSC. The normal message flow that works is the standard: 1. NowSMS MMSC ----> SMSC ----------- SMS[m-notify-ind(path/to/msg)] -----------> Phone 2. NowSMS MMSC <---- MMS Proxy <---------- HTTP GET /path/to/msg ---------------- Phone 3. NowSMS MMSC <---- MMS Proxy ---------- 200 OK[m-retrieve-conf] --------------> Phone 4. NowSMS MMSC <---- MMS Proxy <---------- HTTP POST [m-notify-resp] ------------ Phone 5. NowSMS MMSC ----> MMS Proxy ------------------ 200 OK -----------------------> Phone What I'm seeing now is that some phones are trying to establish and SSL tunnel through the MMS Proxy to the MMSC. I don't know why they are trying that, as the URI provided in the m-notify-ind did not have an https URL in it. In any case, our MMS proxy didn't support the CONNECT method so we started seeing: 1. NowSMS MMSC ----> SMSC ----- SMS[m-notify-ind(path/to/msg)] ----> Phone 2. MMS Proxy <--- HTTP CONNECT mms.***.***:443 ---- Phone 3. MMS Proxy ---------- 500 Bad Request ----------> Phone I was able to add support for the CONNECT method on the MMS proxy (it's an nginx server) using a module. After enabling proxy_connect on the nginx server, the signaling becomes: 1. NowSMS MMSC ----> SMSC ------- SMS[m-notify-ind(path/to/msg)] ------> Phone 2. NowSMS MMSC <---- MMS Proxy <---- HTTP CONNECT mms.***.***:443 ------ Phone 3. NowSMS MMSC <---- MMS Proxy --------- 200 Connection Established] --> Phone 3. NowSMS MMSC <---- MMS Proxy <---- HTTP CONNECT mms.***.***:443 ------ Phone 4. NowSMS MMSC <---- MMS Proxy --------- 200 Connection Established] --> Phone 5. NowSMS MMSC <---- MMS Proxy <---- HTTP CONNECT mms.***.***:443 ------ Phone 6. NowSMS MMSC <---- MMS Proxy --------- 200 Connection Established] --> Phone Closer, but still not working. The issue now is a TLSv1.2 handshake failure. The phone is re-trying three times and then giving up. From a tcpdump, I'm see the phone send in a Client Hello TLSv1.2 request, but then I'm seeing the NowSMS return a Alert (Level: Fatal, Description: Handshake Failure). I see 21 Cipher suites iand 11 Signature Hash Algorithms in the Client Hello. I have my SSL.CA file in the C:\Program Files (x86)\NowSMS directory with a valid and current wildcard cert (with full signing chain). The smsssl.dll file is dated 04/12/2019 (1.06MB in size). I don't know if there's a newer one or not. The ones in some of the older articles on here are from 2014, so I'm assuming I'm at least better than those versions. Is there a way to debug this further on the NowSMS? I don't see anything related to TLS in the MMSCDEBUG, MMSC-xxxx, SMPPDEBUG, or SMSDEBUG log files. The NowSMS server is version v2020.01.15 and is running on a Windows 10 Pro VM. Any pointers on how I can dig deeper into why the handshake is failing? Thanks! //Robert | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8496 Registered: 10-2002 |
Hi Robert, It makes no sense why the mobile would be trying to establish a TLS connection when the path in the notification URI does not use https. This is difficult to troubleshoot, but I would start by testing https requests via a web browser, in order to make sure that you do not have certificate issues. Place a text file in the MMSCDATA directory. Give it a simple name like test.txt. From a web browser, try to request http://mmsc/test.txt, and you should see this text file. Next try to request https://mmsc/test.txt One potential issue that comes to my mind is whether you are using a DNS host name or an IP address in the notification URI. You can't associate an IP address with a certificate, to the best of my knowledge, so that would produce a certificate error. Regards, Bryce Now SMS/MMS Support | |||
| Robert Barretto Frequent Contributor Username: Barretto Post Number: 70 Registered: 09-2019 |
Hi Bryce, Thanks for the reply. I tested using curl -vvv and the error is "no common encryption algorithm(s)." curl -vvv "https://mms.*******.com/test.txt" * Trying 192.168.69.36:443... * Connected to mms.*******.com (192.168.69.36) port 443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: none * CApath: none * loaded libnssckbi.so * NSS error -12286 (SSL_ERROR_NO_CYPHER_OVERLAP) * Cannot communicate securely with peer: no common encryption algorithm(s). * Closing connection 0 curl: (35) Cannot communicate securely with peer: no common encryption algorithm(s). I get the same output if I use --tls-max 1.2 or --tls-max 1.3. If I try --tls-max 1.1 the request gets rejected for unsupported protocol version. Which makes sense as TLSv1.1 is being phased out. curl -vvv --tls-max 1.1 "https://mms.*******.com/test.txt" * Trying 192.168.69.36:443... * Connected to mms.*******.com (192.168.69.36) port 443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: none * CApath: none * loaded libnssckbi.so * NSS error -12190 (SSL_ERROR_PROTOCOL_VERSION_ALERT) * Peer reports incompatible or unsupported protocol version. * Closing connection 0 curl: (35) Peer reports incompatible or unsupported protocol version. I guess the next step is to figure out which cipher suites are installed on the Windows side? I would have thought the TLSv1.3 would have worked. I'll keep digging and let you know what I see. Thanks! //Robert | |||
| Robert Barretto Frequent Contributor Username: Barretto Post Number: 71 Registered: 09-2019 |
Hi Bryce, Do you know which cipher suites the web server component of the MMS supports? I used Windows Local Group Policy Editor and verified that the SSL Cipher Suite Order (Computer Confiugration > Administrative Templates > Network > SSL Confiugraiton Settings > SSL Cipher Suite Order) has the default list of cipher suites: TLS_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA 384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_EC DHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECD SA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256,TL S_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WI TH_NULL_SHA256,TLS_RSA_WITH_NULL_SHA,TLS_PSK_WITH_AES_256_GCM_SHA384,TLS_PSK_WITH_AES_128_GCM_SHA256,TLS_PSK_WITH_AES_256_CBC_SHA384,TLS_PSK_WITH_AES_128_CBC_SH A256,TLS_PSK_WITH_NULL_SHA384,TLS_PSK_WITH_NULL_SHA256 I used Wireshark to see the list of cipher suites supported by the cllient on the in coming Client Helllo: Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 508 Version: TLS 1.2 (0x0303) Random: fcdd802e0ae6b021fdbc4422b0b3bd251fa1b05b2e24c1ee… Session ID Length: 0 Cipher Suites Length: 62 Cipher Suites (31 suites) Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301) Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303) Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e) Cipher Suite: TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xccaa) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d) Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) The third one from the client is the first one on Windows' list of ciphers, so there shouldn't be an issue with not finding a matching cipher in Windows itself. However, the HTTP server receiving the incoming TLS handshake is whatever internal server y'all are using inside the NowSMS binary itself, and wouldn't use the Windows group policy list of supported ciphers. For example, if I install an Apache server on a Windows box, the ciphers supported for that Apache service are defined in the JVM running the Apache server, not what Windows has configured. Do you know what the list of supported ciphers that the MMSC HTTP process supports? The version of the NowSMS/MMS Gateway shows: v2020.01.15 Thanks, //Robert | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8497 Registered: 10-2002 |
Hi Robert, All of this sounds like your certificate is not being accepted by the client, or the NowSMS server does not understand the format of the certificate, or the certificate file is not in the correct location, or the private key does not match the certificate because you are trying to apply an existing certificate that was generated by another server. I like to recommend that you try interactive requests with a web browser, because those errors tend to be a bit more user friendly. Did you generate a CSR via NowSMS, and then use that to request a certificate? Or are you trying to use a "current and valid wildcard cert" that was generated for another server? It is possible to use a certificate that was generated for another server, but you must also copy over the private key and save it in the file SSL.KEY. When manually copying a certificate from another server, also copy SSL.CA as SSL.CRT. And make sure to restart the service after making any changed to these certificate files. If this doesn't resolve your issue, the quickest way to resolve this would be if you could send me these SSL.* files at nowsmstech@nowsms.com so that I can check the formatting. Regards, Bryce | |||
| Robert Barretto Frequent Contributor Username: Barretto Post Number: 72 Registered: 09-2019 |
Hi Bryce, That was it! Turns out, back in 2020, I had tried using a self-signed cert (this was before we had a real one to use) and I hadn't cleaned all that old stuff out. Specifically, I had removed the SSL.CRT but I had accidentally left the SSL.KEY file. So now, when I copied over my new SSL.CRT and SSL.KEY files into the NowSMS directory, the SSL.CRT file copied fine, but Windows didn't overwrite the existing SSL.KEY file, it just renamed my new file to "SSL - Copy.KEY" and left the old SSL.KEY file untouched. So I had the new SSL.CRT but the old SSL.KEY. Which definitely would not work. I removed that old key file and renamed my new key back to SSL.KEY and then restarted the service and now it's all working. Woot! I really should have double checked the folder after my copy. That's what I get for using Windows and not Linux. lol. Thanks for your help! Cheers! //Robert | |||
