Re: [Twisted-Python] Regarding the SHA 512 support in twisted.
Hi Team, Wanted to bring one code changes which is really required from twisted side otherwise it is not behaving as per RFC (rfc4253 Section 7.2), twisted is failing when we negotiate any kex algorithm based on SHA1 and we have MAC as hmac-sha2-512. The reason for the failure was the below code hashProcessor = _kex.getHashProcessor(self.kexAlg) k1 = hashProcessor(sharedSecret + exchangeHash + c + self.sessionID) k1 = k1.digest() k2 = hashProcessor(sharedSecret + exchangeHash + k1).digest() return k1 + k2 For SHA512 we need 64 byte key and if the Kex is based on SHA1 then it will only generate 40 byte key and that induce a failure. So we need to modify the code as below to make it generic and make it comply with RFC (rfc4253 Section 7.2). So that twisted can work irrespective of what kex is been used. Actual code should plot in is like below hashProcessor = _kex.getHashProcessor(self.kexAlg) k1 = hashProcessor(sharedSecret + exchangeHash + c + self.sessionID) k1 = k1.digest() k2 = hashProcessor(sharedSecret + exchangeHash + k1).digest() k3 = hashProcessor(sharedSecret + exchangeHash + k1 + k2).digest() k4 = hashProcessor(sharedSecret + exchangeHash + k1 + k2 + k3).digest() return k1 + k2 + k3 + k4 Can somebody help me to plot this fix so that twisted will work fine with all the other servers out there and even make it comply to the RFC. Thanks in advance and this will be my first findings on twisted code ;). Please let me know in case of any doubt on the same. Code changes should be plotted in to the routine _getKey, file name is src/twisted/conch/ssh/transport.py . Please help me with this commit team. Thanks, Jabir \|/ ------- ( o o ) oooO---O---Oooonull From: Alex Gaynor <alex.gaynor@gmail.com<mailto:alex.gaynor@gmail.com>> Date: Wednesday, 1 March 2017 9:26 am To: jabir mohammed <jamohamm@cisco.com<mailto:jamohamm@cisco.com>> Cc: Itamar Turner-Trauring <itamar@itamarst.org<mailto:itamar@itamarst.org>>, "security@twistedmatrix.com<mailto:security@twistedmatrix.com>" <security@twistedmatrix.com<mailto:security@twistedmatrix.com>> Subject: Re: Regarding the SHA 512 support in twisted. This doesn't appear to be a security issue. You can file an issue on the public tracker. Alex On Tue, Feb 28, 2017 at 10:54 PM, jabir Mohammed (jamohamm) <jamohamm@cisco.com<mailto:jamohamm@cisco.com>> wrote: Thanks Alex for the response. In our server we added support of HMAC-SHA-512 and HMAC-SHA-256 support for MAC. When we try to negotiate this hmac with most of the other client like Paramiko, OpenSSH and other flavours of SSH its working fine. But we are seeing a problem with twisted client that too only with HMAC-SHA-512. We have a limitation from our side to debug this since we don’t know what is happening from the client side. We have taken our derived key for the HMAC and as well as the input to derive the MAC using online tools and it matches with whatever we have generated but whatever is been sent across the other Twisted side differs and we are closing the session. This is been tagged critical since most of the customers are migrating to Twisted and will be a deployment blocker for us. What we suspect is the key or the algorithm itself. Please see the snippet below This is our inmac Key ---------------------------- RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: ssh_integrity_check: inmac.key RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0000<tel:0000> - a5 cb a5 bb 4c 34 a7 bf-95 e9 00 23 1e 09 17 0c ....L4.....#.... RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0010<tel:0010> - 1c e1 3f d9 a7 42 d9 87-54 23 64 16 e5 e2 c3 76 ..?..B..T#d....v RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0020<tel:0020> - 2a bc 53 c6 85 78 81 eb-e4 3e fb f7 cc a3 1f 6e *.S..x...>.....n RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0030<tel:0030> - d9 a5 0e 73 d0 44 79 a9-d3 19 32 3b 26 92 bb 70 ...s.Dy...2;&..p<http://s.Dy...2;&..p> This is our input data to the hmac-sha-512 ----------------------------------------------------- RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: ssh_integrity_check: input.data to HMAC API RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0000<tel:0000> - 00 00 00 03 00 00 00 1c-0a 05 00 00 00 0c 73 73 ..............ss RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0010<tel:0010> - 68 2d 75 73 65 72 61 75-74 68 64 de 66 fb ab 31 h-userauthd.f..1 RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0020<tel:0020> - ba 7e 56 e5 .~V. The digest which is been sent from the twisted client side(Red) ----------------------------------------------------------------------- RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: ssh_integrity_check: digest RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0000<tel:0000> - 95 f7 99 27 48 28 35 da-62 92 0e 51 0f af 62 b1 ...'H(5.b..Q..b. RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0010<tel:0010> - 93 d1 4d 46 5f d9 21 7a-b9 fb 86 b6 6e 00 a3 aa ..MF_.!z....n... RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0020<tel:0020> - 84 a9 58 60 5e 1c 86 98-b4 1f 00 40 d5 72 aa cf ..X`^......@.r.. RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0030<tel:0030> - 4b 1d 05 2d a4 68 96 9c-7b c7 9d 83 1d c2 1d 5b K..-.h..{……[ The digest which got created from our side using the same key and input data mentioned above(Green) ——————————————————————————————————————————————————————————————— RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0000<tel:0000> - 36 36 5c 6e 2d be f1 d8-ae 4f 5a 72 30 2d 25 c0 66\n-....OZr0-%. RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0010<tel:0010> - 0e e8 d6 96 6e 10 38 af-65 15 51 ff a7 ca 7d b4 ....n.8.e.Q...}. RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0020<tel:0020> - 7c c8 15 b8 5a 9b 5e c4-b5 ac 4c 51 7e de 77 41 |...Z.^...LQ~.wA RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0030<tel:0030> - 32 63 61 5e f5 1a 31 d1-f7 89 d0 0b 11 3c 48 f6 2ca^..1......<H. If you see the details this is the useauth first packet and we are not able to proceed because of the failure. We used online tool to do this calculation and we are getting the same output as what we generated so the one marked as red is creating problem.So the root cause could be either the key which is been derived or the algorithm so to debug that we need to enable details logging from client side. We can share the details with respective engineer and show what we are facing. Please help. Online tool which we used to check our algorithm is: which result in same MAC marked as green. https://www.liavaag.org/English/SHA-Generator/HMAC/ Thanks, Jabir \|/ ------- ( o o ) oooO---O---Oooonull From: Alex Gaynor <alex.gaynor@gmail.com<mailto:alex.gaynor@gmail.com>> Date: Wednesday, 1 March 2017 6:39 am To: Itamar Turner-Trauring <itamar@itamarst.org<mailto:itamar@itamarst.org>> Cc: jabir mohammed <jamohamm@cisco.com<mailto:jamohamm@cisco.com>>, "security@twistedmatrix.com<mailto:security@twistedmatrix.com>" <security@twistedmatrix.com<mailto:security@twistedmatrix.com>> Subject: Re: FW: Regarding the SHA 512 support in twisted. Hi, I think I'm missing some context here, what part of twisted are you trying to use SHA-512 for a MAC with? It sounds like Conch? Can you show how I could reproduce the problem? Alex On Tue, Feb 28, 2017 at 8:06 PM, Itamar Turner-Trauring <itamar@itamarst.org<mailto:itamar@itamarst.org>> wrote: Hi, Forwarding on to security contact to see if they think it's a security problem; otherwise you can probably just file a normal ticket. On Tue, Feb 28, 2017, at 05:01 AM, jabir Mohammed (jamohamm) wrote: Hi Team, Wanted to cross check on SHA 512 algorithm as MAC while using twisted. Few of our customers started using Twisted and even we are trying to incorporate some scripts via twisted client. But what we have noticed is that when we negotiate SHA 512 MAC with twisted we always get a failure and other MAC algorithms are working fine with twisted. So wanted to cross check do we have any bug or any issue with SHA 512 and twisted and how we can debug this from twisted side. We checked the same with other OpenSSH client and even paramiko things work perfectly fine so wanted to debug further from the twisted side. We checked with the same derived key and the output whatever we got from SHA 512 is what we are getting from the online tool so we suspect something to do with the key or hash algorithm from the other side. We used the twisted 16.6.0 version for testing, thanks in advance for looking in to this email. Thanks, Jabir \|/ ------- ( o o ) oooO---O---Oooonull -- Itamar Turner-Trauring -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: D1B3 ADC0 E023 8CA6 -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: D1B3 ADC0 E023 8CA6
Hi Jarib, Thanks for the details. On 27 March 2017 at 10:33, jabir Mohammed (jamohamm) <jamohamm@cisco.com> wrote:
Hi Team,
Wanted to bring one code changes which is really required from twisted side otherwise it is not behaving as per RFC (rfc4253 Section 7.2), twisted is failing when we negotiate any kex algorithm based on SHA1 and we have MAC as hmac-sha2-512. The reason for the failure was the below code
hashProcessor = _kex.getHashProcessor(self.kexAlg) k1 = hashProcessor(sharedSecret + exchangeHash + c + self.sessionID) k1 = k1.digest() k2 = hashProcessor(sharedSecret + exchangeHash + k1).digest() return k1 + k2
For SHA512 we need 64 byte key and if the Kex is based on SHA1 then it will only generate 40 byte key and that induce a failure. So we need to modify the code as below to make it generic and make it comply with RFC (rfc4253 Section 7.2). So that twisted can work irrespective of what kex is been used. Actual code should plot in is like below
hashProcessor = _kex.getHashProcessor(self.kexAlg) k1 = hashProcessor(sharedSecret + exchangeHash + c + self.sessionID) k1 = k1.digest() k2 = hashProcessor(sharedSecret + exchangeHash + k1).digest() k3 = hashProcessor(sharedSecret + exchangeHash + k1 + k2).digest() k4 = hashProcessor(sharedSecret + exchangeHash + k1 + k2 + k3).digest() return k1 + k2 + k3 + k4
Can somebody help me to plot this fix so that twisted will work fine with all the other servers out there and even make it comply to the RFC. Thanks in advance and this will be my first findings on twisted code ;). Please let me know in case of any doubt on the same. Code changes should be plotted in to the routine _getKey, file name is src/twisted/conch/ssh/transport.py . Please help me with this commit team.
Happy to help. Here should be the documentation for contributing (hopefully is up to date) http://twistedmatrix.com/trac/wiki/TwistedDevelopment The first thing is to fork twisted/twisted, apply the change on the branch and then create a PR. By creating the PR, you will trigger some of the automated tests and you can get a quick feedback. .. for example to see if your changes are not introducing any regressions. In an ideal world before making the changes and creating a simple example so that we can manually check the changes you start by updating the existing automated test to make sure that we don't introduce regressions in the feature (as a non exhaustive list of reasons) You can use this file https://github.com/twisted/twisted/blob/trunk/docs/conch/examples/sshsimples... as the foundation for a simple example. In the PR you can provide the client-side command use for the manual test Looking forward for you PR. I can help with the review and/or writing the automated tests. You can also find me on #twisted-dev Thanks, Adi
From: Alex Gaynor <alex.gaynor@gmail.com> Date: Wednesday, 1 March 2017 9:26 am To: jabir mohammed <jamohamm@cisco.com> Cc: Itamar Turner-Trauring <itamar@itamarst.org>, "security@twistedmatrix.com" <security@twistedmatrix.com> Subject: Re: Regarding the SHA 512 support in twisted.
This doesn't appear to be a security issue. You can file an issue on the public tracker.
Alex
On Tue, Feb 28, 2017 at 10:54 PM, jabir Mohammed (jamohamm) <jamohamm@cisco.com> wrote:
Thanks Alex for the response. In our server we added support of HMAC-SHA-512 and HMAC-SHA-256 support for MAC. When we try to negotiate this hmac with most of the other client like Paramiko, OpenSSH and other flavours of SSH its working fine. But we are seeing a problem with twisted client that too only with HMAC-SHA-512. We have a limitation from our side to debug this since we don’t know what is happening from the client side. We have taken our derived key for the HMAC and as well as the input to derive the MAC using online tools and it matches with whatever we have generated but whatever is been sent across the other Twisted side differs and we are closing the session. This is been tagged critical since most of the customers are migrating to Twisted and will be a deployment blocker for us.
What we suspect is the key or the algorithm itself. Please see the snippet below
This is our inmac Key ---------------------------- RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: ssh_integrity_check: inmac.key RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0000 - a5 cb a5 bb 4c 34 a7 bf-95 e9 00 23 1e 09 17 0c ....L4.....#.... RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0010 - 1c e1 3f d9 a7 42 d9 87-54 23 64 16 e5 e2 c3 76 ..?..B..T#d....v RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0020 - 2a bc 53 c6 85 78 81 eb-e4 3e fb f7 cc a3 1f 6e *.S..x...>.....n RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0030 - d9 a5 0e 73 d0 44 79 a9-d3 19 32 3b 26 92 bb 70 ...s.Dy...2;&..p
This is our input data to the hmac-sha-512 ----------------------------------------------------- RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: ssh_integrity_check: input.data to HMAC API RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0000 - 00 00 00 03 00 00 00 1c-0a 05 00 00 00 0c 73 73 ..............ss RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0010 - 68 2d 75 73 65 72 61 75-74 68 64 de 66 fb ab 31 h-userauthd.f..1 RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0020 - ba 7e 56 e5 .~V.
The digest which is been sent from the twisted client side(Red) ----------------------------------------------------------------------- RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: ssh_integrity_check: digest RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0000 - 95 f7 99 27 48 28 35 da-62 92 0e 51 0f af 62 b1 ...'H(5.b..Q..b. RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0010 - 93 d1 4d 46 5f d9 21 7a-b9 fb 86 b6 6e 00 a3 aa ..MF_.!z....n... RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0020 - 84 a9 58 60 5e 1c 86 98-b4 1f 00 40 d5 72 aa cf ..X`^......@.r.. RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0030 - 4b 1d 05 2d a4 68 96 9c-7b c7 9d 83 1d c2 1d 5b K..-.h..{……[
The digest which got created from our side using the same key and input data mentioned above(Green) ——————————————————————————————————————————————————————————————— RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0000 - 36 36 5c 6e 2d be f1 d8-ae 4f 5a 72 30 2d 25 c0 66\n-....OZr0-%. RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0010 - 0e e8 d6 96 6e 10 38 af-65 15 51 ff a7 ca 7d b4 ....n.8.e.Q...}. RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0020 - 7c c8 15 b8 5a 9b 5e c4-b5 ac 4c 51 7e de 77 41 |...Z.^...LQ~.wA RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0030 - 32 63 61 5e f5 1a 31 d1-f7 89 d0 0b 11 3c 48 f6 2ca^..1......<H.
If you see the details this is the useauth first packet and we are not able to proceed because of the failure. We used online tool to do this calculation and we are getting the same output as what we generated so the one marked as red is creating problem.So the root cause could be either the key which is been derived or the algorithm so to debug that we need to enable details logging from client side. We can share the details with respective engineer and show what we are facing. Please help.
Online tool which we used to check our algorithm is: which result in same MAC marked as green.
https://www.liavaag.org/English/SHA-Generator/HMAC/
Thanks,
Jabir
\|/
-------
( o o )
oooO---O---Oooonull
From: Alex Gaynor <alex.gaynor@gmail.com> Date: Wednesday, 1 March 2017 6:39 am To: Itamar Turner-Trauring <itamar@itamarst.org> Cc: jabir mohammed <jamohamm@cisco.com>, "security@twistedmatrix.com" <security@twistedmatrix.com> Subject: Re: FW: Regarding the SHA 512 support in twisted.
Hi,
I think I'm missing some context here, what part of twisted are you trying to use SHA-512 for a MAC with? It sounds like Conch? Can you show how I could reproduce the problem?
Alex
On Tue, Feb 28, 2017 at 8:06 PM, Itamar Turner-Trauring <itamar@itamarst.org> wrote:
Hi,
Forwarding on to security contact to see if they think it's a security problem; otherwise you can probably just file a normal ticket.
On Tue, Feb 28, 2017, at 05:01 AM, jabir Mohammed (jamohamm) wrote:
Hi Team,
Wanted to cross check on SHA 512 algorithm as MAC while using twisted. Few of our customers started using Twisted and even we are trying to incorporate some scripts via twisted client. But what we have noticed is that when we negotiate SHA 512 MAC with twisted we always get a failure and other MAC algorithms are working fine with twisted. So wanted to cross check do we have any bug or any issue with SHA 512 and twisted and how we can debug this from twisted side.
We checked the same with other OpenSSH client and even paramiko things work perfectly fine so wanted to debug further from the twisted side. We checked with the same derived key and the output whatever we got from SHA 512 is what we are getting from the online tool so we suspect something to do with the key or hash algorithm from the other side.
We used the twisted 16.6.0 version for testing, thanks in advance for looking in to this email.
-- Adi Roiban
No probs Adi, can you help me to upload the fix to the twisted since I don¹t know the procedure, if you can guide me that helps. Since I was pretty sure that this a bug in coding twisted set keys part and not comply to RFC. Thanks, Jabir \|/ ------- ( o o ) oooO---O---Oooonull On 27/03/17 4:06 pm, "Twisted-Python on behalf of Adi Roiban" <twisted-python-bounces@twistedmatrix.com on behalf of adi@roiban.ro> wrote:
Hi Jarib,
Thanks for the details.
On 27 March 2017 at 10:33, jabir Mohammed (jamohamm) <jamohamm@cisco.com> wrote:
Hi Team,
Wanted to bring one code changes which is really required from twisted side otherwise it is not behaving as per RFC (rfc4253 Section 7.2), twisted is failing when we negotiate any kex algorithm based on SHA1 and we have MAC as hmac-sha2-512. The reason for the failure was the below code
hashProcessor = _kex.getHashProcessor(self.kexAlg) k1 = hashProcessor(sharedSecret + exchangeHash + c + self.sessionID) k1 = k1.digest() k2 = hashProcessor(sharedSecret + exchangeHash + k1).digest() return k1 + k2
For SHA512 we need 64 byte key and if the Kex is based on SHA1 then it will only generate 40 byte key and that induce a failure. So we need to modify the code as below to make it generic and make it comply with RFC (rfc4253 Section 7.2). So that twisted can work irrespective of what kex is been used. Actual code should plot in is like below
hashProcessor = _kex.getHashProcessor(self.kexAlg) k1 = hashProcessor(sharedSecret + exchangeHash + c + self.sessionID) k1 = k1.digest() k2 = hashProcessor(sharedSecret + exchangeHash + k1).digest() k3 = hashProcessor(sharedSecret + exchangeHash + k1 + k2).digest() k4 = hashProcessor(sharedSecret + exchangeHash + k1 + k2 + k3).digest() return k1 + k2 + k3 + k4
Can somebody help me to plot this fix so that twisted will work fine with all the other servers out there and even make it comply to the RFC. Thanks in advance and this will be my first findings on twisted code ;). Please let me know in case of any doubt on the same. Code changes should be plotted in to the routine _getKey, file name is src/twisted/conch/ssh/transport.py . Please help me with this commit team.
Happy to help.
Here should be the documentation for contributing (hopefully is up to date)
http://twistedmatrix.com/trac/wiki/TwistedDevelopment
The first thing is to fork twisted/twisted, apply the change on the branch and then create a PR.
By creating the PR, you will trigger some of the automated tests and you can get a quick feedback. .. for example to see if your changes are not introducing any regressions.
In an ideal world before making the changes and creating a simple example so that we can manually check the changes you start by updating the existing automated test to make sure that we don't introduce regressions in the feature (as a non exhaustive list of reasons)
You can use this file https://github.com/twisted/twisted/blob/trunk/docs/conch/examples/sshsimpl eserver.py as the foundation for a simple example. In the PR you can provide the client-side command use for the manual test
Looking forward for you PR. I can help with the review and/or writing the automated tests.
You can also find me on #twisted-dev
Thanks, Adi
From: Alex Gaynor <alex.gaynor@gmail.com> Date: Wednesday, 1 March 2017 9:26 am To: jabir mohammed <jamohamm@cisco.com> Cc: Itamar Turner-Trauring <itamar@itamarst.org>, "security@twistedmatrix.com" <security@twistedmatrix.com> Subject: Re: Regarding the SHA 512 support in twisted.
This doesn't appear to be a security issue. You can file an issue on the public tracker.
Alex
On Tue, Feb 28, 2017 at 10:54 PM, jabir Mohammed (jamohamm) <jamohamm@cisco.com> wrote:
Thanks Alex for the response. In our server we added support of HMAC-SHA-512 and HMAC-SHA-256 support for MAC. When we try to negotiate this hmac with most of the other client like Paramiko, OpenSSH and other flavours of SSH its working fine. But we are seeing a problem with twisted client that too only with HMAC-SHA-512. We have a limitation from our side to debug this since we don¹t know what is happening from the client side. We have taken our derived key for the HMAC and as well as the input to derive the MAC using online tools and it matches with whatever we have generated but whatever is been sent across the other Twisted side differs and we are closing the session. This is been tagged critical since most of the customers are migrating to Twisted and will be a deployment blocker for us.
What we suspect is the key or the algorithm itself. Please see the snippet below
This is our inmac Key ---------------------------- RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: ssh_integrity_check: inmac.key RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0000 - a5 cb a5 bb 4c 34 a7 bf-95 e9 00 23 1e 09 17 0c ....L4.....#.... RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0010 - 1c e1 3f d9 a7 42 d9 87-54 23 64 16 e5 e2 c3 76 ..?..B..T#d....v RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0020 - 2a bc 53 c6 85 78 81 eb-e4 3e fb f7 cc a3 1f 6e *.S..x...>.....n RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0030 - d9 a5 0e 73 d0 44 79 a9-d3 19 32 3b 26 92 bb 70 ...s.Dy...2;&..p
This is our input data to the hmac-sha-512 ----------------------------------------------------- RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: ssh_integrity_check: input.data to HMAC API RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0000 - 00 00 00 03 00 00 00 1c-0a 05 00 00 00 0c 73 73 ..............ss RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0010 - 68 2d 75 73 65 72 61 75-74 68 64 de 66 fb ab 31 h-userauthd.f..1 RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0020 - ba 7e 56 e5 .~V.
The digest which is been sent from the twisted client side(Red) ----------------------------------------------------------------------- RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: ssh_integrity_check: digest RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0000 - 95 f7 99 27 48 28 35 da-62 92 0e 51 0f af 62 b1 ...'H(5.b..Q..b. RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0010 - 93 d1 4d 46 5f d9 21 7a-b9 fb 86 b6 6e 00 a3 aa ..MF_.!z....n... RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0020 - 84 a9 58 60 5e 1c 86 98-b4 1f 00 40 d5 72 aa cf ..X`^......@.r.. RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0030 - 4b 1d 05 2d a4 68 96 9c-7b c7 9d 83 1d c2 1d 5b K..-.h..{ŠŠ[
The digest which got created from our side using the same key and input data mentioned above(Green) ‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹ RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0000 - 36 36 5c 6e 2d be f1 d8-ae 4f 5a 72 30 2d 25 c0 66\n-....OZr0-%. RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0010 - 0e e8 d6 96 6e 10 38 af-65 15 51 ff a7 ca 7d b4 ....n.8.e.Q...}. RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0020 - 7c c8 15 b8 5a 9b 5e c4-b5 ac 4c 51 7e de 77 41 |...Z.^...LQ~.wA RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0030 - 32 63 61 5e f5 1a 31 d1-f7 89 d0 0b 11 3c 48 f6 2ca^..1......<H.
If you see the details this is the useauth first packet and we are not able to proceed because of the failure. We used online tool to do this calculation and we are getting the same output as what we generated so the one marked as red is creating problem.So the root cause could be either the key which is been derived or the algorithm so to debug that we need to enable details logging from client side. We can share the details with respective engineer and show what we are facing. Please help.
Online tool which we used to check our algorithm is: which result in same MAC marked as green.
https://www.liavaag.org/English/SHA-Generator/HMAC/
Thanks,
Jabir
\|/
-------
( o o )
oooO---O---Oooonull
From: Alex Gaynor <alex.gaynor@gmail.com> Date: Wednesday, 1 March 2017 6:39 am To: Itamar Turner-Trauring <itamar@itamarst.org> Cc: jabir mohammed <jamohamm@cisco.com>, "security@twistedmatrix.com" <security@twistedmatrix.com> Subject: Re: FW: Regarding the SHA 512 support in twisted.
Hi,
I think I'm missing some context here, what part of twisted are you trying to use SHA-512 for a MAC with? It sounds like Conch? Can you show how I could reproduce the problem?
Alex
On Tue, Feb 28, 2017 at 8:06 PM, Itamar Turner-Trauring <itamar@itamarst.org> wrote:
Hi,
Forwarding on to security contact to see if they think it's a security problem; otherwise you can probably just file a normal ticket.
On Tue, Feb 28, 2017, at 05:01 AM, jabir Mohammed (jamohamm) wrote:
Hi Team,
Wanted to cross check on SHA 512 algorithm as MAC while using twisted. Few of our customers started using Twisted and even we are trying to incorporate some scripts via twisted client. But what we have noticed is that when we negotiate SHA 512 MAC with twisted we always get a failure and other MAC algorithms are working fine with twisted. So wanted to cross check do we have any bug or any issue with SHA 512 and twisted and how we can debug this from twisted side.
We checked the same with other OpenSSH client and even paramiko things work perfectly fine so wanted to debug further from the twisted side. We checked with the same derived key and the output whatever we got from SHA 512 is what we are getting from the online tool so we suspect something to do with the key or hash algorithm from the other side.
We used the twisted 16.6.0 version for testing, thanks in advance for looking in to this email.
-- Adi Roiban
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
On Mon, Mar 27, 2017 at 2:33 AM, jabir Mohammed (jamohamm) < jamohamm@cisco.com> wrote:
Can somebody help me to plot this fix so that twisted will work fine with all the other servers out there and even make it comply to the RFC. Thanks in advance and this will be my first findings on twisted code ;). Please let me know in case of any doubt on the same. Code changes should be plotted in to the routine _getKey, file name is src/twisted/conch/ssh/transport.py . Please help me with this commit team.
You need to follow the procedure at: https://twistedmatrix.com/trac/wiki/TwistedDevelopment#SubmittingaPatch That will give you all the details you need about filing a new ticket in Trac, forking the repository on GitHub, doing a GitHub pull request, etc. If you need more help, you should ask Einar Floystad Dorum, who works at Cisco and has filed multiple Conch patches for Twisted: https://github.com/twisted/twisted/pulls?q=is%3Apr+author%3Aeinarfd+is%3Aclo... -- Craig
Thanks Craig shall follow up. Thanks, Jabir \|/ ------- ( o o ) oooO---O---Oooonull From: <crodr001@gmail.com<mailto:crodr001@gmail.com>> on behalf of Craig Rodrigues <rodrigc@crodrigues.org<mailto:rodrigc@crodrigues.org>> Date: Monday, 27 March 2017 9:38 pm To: Twisted general discussion <twisted-python@twistedmatrix.com<mailto:twisted-python@twistedmatrix.com>> Cc: "security@twistedmatrix.com<mailto:security@twistedmatrix.com>" <security@twistedmatrix.com<mailto:security@twistedmatrix.com>>, "twisted-python-bounces@twistedmatrix.com<mailto:twisted-python-bounces@twistedmatrix.com>" <twisted-python-bounces@twistedmatrix.com<mailto:twisted-python-bounces@twistedmatrix.com>>, jabir mohammed <jamohamm@cisco.com<mailto:jamohamm@cisco.com>> Subject: Re: [Twisted-Python] Regarding the SHA 512 support in twisted. On Mon, Mar 27, 2017 at 2:33 AM, jabir Mohammed (jamohamm) <jamohamm@cisco.com<mailto:jamohamm@cisco.com>> wrote: Can somebody help me to plot this fix so that twisted will work fine with all the other servers out there and even make it comply to the RFC. Thanks in advance and this will be my first findings on twisted code ;). Please let me know in case of any doubt on the same. Code changes should be plotted in to the routine _getKey, file name is src/twisted/conch/ssh/transport.py . Please help me with this commit team. You need to follow the procedure at: https://twistedmatrix.com/trac/wiki/TwistedDevelopment#SubmittingaPatch That will give you all the details you need about filing a new ticket in Trac, forking the repository on GitHub, doing a GitHub pull request, etc. If you need more help, you should ask Einar Floystad Dorum, who works at Cisco and has filed multiple Conch patches for Twisted: https://github.com/twisted/twisted/pulls?q=is%3Apr+author%3Aeinarfd+is%3Aclo... -- Craig
participants (3)
-
Adi Roiban -
Craig Rodrigues -
jabir Mohammed (jamohamm)