Hi Jarib, Thanks for the details.
On 27 March 2017 at 10:33, jabir Mohammed (jamohamm) <jamoh...@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/sshsimpleserver.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.gay...@gmail.com> > Date: Wednesday, 1 March 2017 9:26 am > To: jabir mohammed <jamoh...@cisco.com> > Cc: Itamar Turner-Trauring <ita...@itamarst.org>, > "secur...@twistedmatrix.com" <secur...@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) > <jamoh...@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.gay...@gmail.com> >> Date: Wednesday, 1 March 2017 6:39 am >> To: Itamar Turner-Trauring <ita...@itamarst.org> >> Cc: jabir mohammed <jamoh...@cisco.com>, "secur...@twistedmatrix.com" >> <secur...@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 >> <ita...@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
