[Twisted-Python] Regarding the SHA 512 support in twisted.

jabir Mohammed (jamohamm) jamohamm at cisco.com
Mon Mar 27 05:11:10 MDT 2017 

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 at twistedmatrix.com on behalf of adi at roiban.ro>
wrote:

>Hi Jarib,
>
>Thanks for the details.
>
>On 27 March 2017 at 10:33, jabir Mohammed (jamohamm) <jamohamm at 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 at gmail.com>
>> Date: Wednesday, 1 March 2017 9:26 am
>> To: jabir mohammed <jamohamm at cisco.com>
>> Cc: Itamar Turner-Trauring <itamar at itamarst.org>,
>> "security at twistedmatrix.com" <security at 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 at 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`^...... at .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 at gmail.com>
>>> Date: Wednesday, 1 March 2017 6:39 am
>>> To: Itamar Turner-Trauring <itamar at itamarst.org>
>>> Cc: jabir mohammed <jamohamm at cisco.com>, "security at twistedmatrix.com"
>>> <security at 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 at 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 at twistedmatrix.com
>http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

More information about the Twisted-Python mailing list