On 27 March 2017 at 12:07, jabir Mohammed (jamohamm) <jamoh...@cisco.com> wrote: > > Its a security issue even you are allowing a weaker key in case of 64 bytes > deriving only 40 bytes. Let me know how we issue a tracker bug can you > please guide me. Since don’t want someone else to waist effort in debugging > the same issue.
Hi Jabir and sorry for the previous misspelling! There are a few existing bug reports for KEX related tasks...some are server side, some are client side https://twistedmatrix.com/trac/search?q=kex I think that your bug was already reported (by my) at https://twistedmatrix.com/trac/ticket/8258 --------- Regarding the help with this patch. What have you tried so far? Where are you stuck? Where/ with what specifically do you need help? Thanks! > > Thanks, > > Jabir > > \|/ > > ------- > > ( o o ) > > oooO---O---Oooonull > > > From: Alex Gaynor <alex.gay...@gmail.com> > Date: Monday, 27 March 2017 4:34 pm > To: jabir mohammed <jamoh...@cisco.com> > Cc: Itamar Turner-Trauring <ita...@itamarst.org>, > "secur...@twistedmatrix.com" <secur...@twistedmatrix.com>, Twisted general > discussion <twisted-python@twistedmatrix.com>, > "twisted-python-boun...@twistedmatrix.com" > <twisted-python-boun...@twistedmatrix.com> > Subject: Re: Regarding the SHA 512 support in twisted. > > This is not a security issue, so this address isn't the right place for this > discussion. Please use the public twisted issue tracker. > > Alex > > On Mon, Mar 27, 2017 at 5:33 AM, 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. >> >> >> Thanks, >> >> Jabir >> >> \|/ >> >> ------- >> >> ( o o ) >> >> oooO---O---Oooonull >> >> >> 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. >>>> >>>> >>>> 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 >> > > > > -- > "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 > > > _______________________________________________ > Twisted-Python mailing list > Twisted-Python@twistedmatrix.com > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python > -- Adi Roiban _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
