Re: [Opalvoip-devel] H.235.8 - SRTP over H.323
Brought to you by:
csoutheren,
rjongbloed
Menu
▾
▴
Re: [Opalvoip-devel] H.235.8 - SRTP over H.323
|
From: Robert J. <ro...@vo...> - 2013-08-15 00:34:43
|
I have no doubt that h323plus is highly interoperable, I would imagine you guys sweated blood over working out how to get around some big companies broken implementation, that they have so widely deployed it cannot be ignored. 14 years on in this game, and nothing has changed. Thanks for the tip on DHset. *Robert Jongbloed* /OPAL/OpenH323/PTLib Architect and Co-founder./ Commercial support at http://www.voxlucida.com.au On 14/08/2013 11:02 PM, Simon Horne wrote: > Robert > > The h323plus H.235.6 Implementation has been widely tested and the fix Jan > added seems to work pretty much everywhere. > > Another thing you might do is grab the H.235 ASN.1 CVS code from h323plus > too. There is a bug in the current spec H.235v4 that limits the DH size to > 2048 bits (dhset field) but the H.235.6 spec says it can support 4096 bits. > There is a fix in the ITU pipeline which adds a new dhextset field but that > will take a while. I pushed that fix in the ASN.1 code. > > Simon > > -----Original Message----- > From: Jan Willamowius [mailto:ja...@wi...] > Sent: 14 August 2013 17:18 > To: ro...@vo... > Cc: Simon Horne; Opa...@li... > Subject: Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 > > Hi Robert, > > I wrote the low-level crypto for H323Plus and I found similar padding issues > with Polycom endpoints. I don't think this is documented in the > H.235 specs, at least I couldn't find anything, but it seems rather wide > spread. > > Due to the differing padding conventions, you can't use OpenSSL's > EVP_DecryptFinal() for an interoperable decode function. I put a substitute > with relaxed padding checking into src/h235/h235crypto.cxx. > > Regards, > Jan > > Robert Jongbloed wrote: >> Hi Simon, >> while I could not use the actual code, OPAL and H323plus have >> diverged too far over the years, it was very instructive looking at >> the code. Thanks for doing the hard slog understanding the spec! >> >> Anyway, I /almost/ have it working. >> >> I have a question though, regarding RTP padding. The spec I have >> clearly >> states: >> >> [RTP], section 5.1 describes a method of padding in which the >> payload shall be padded to a >> multiple of blocks. The last octet shall be set to the number of >> padding octets (including the last), >> and the P bit set in the RTP header. The value of the pad should be >> determined by the normal >> convention of the cipher algorithm. >> >> however, the system I am testing against (Codian MSE4510) equally >> clearly does not do this! >> >> Is there some implementation note or late revision that states that >> this is an exception to RFC 3550 padding rules? And if so, how do you >> determine how many pad bytes are on the end? >> >> The reason I ask is because the OPAL code has the RFC 3550 padding >> support needed for some other random system. Temporarily disabling >> that code makes it work, but with numerous decode errors on both >> sides, presumably because of the padding. >> >> Note, audio is perfect because a 20ms G.711 packet is exactly >> divisible by the cipher block size. So, no padding occurs. >> >> *Robert Jongbloed* >> /OPAL/OpenH323/PTLib Architect and Co-founder./ Commercial support at >> http://www.voxlucida.com.au >> >> On 11/07/2013 12:32 PM, Simon Horne wrote: >>> Robert >>> >>> Just to clarify in H.323 the agreed industry standard is H.235.6 >>> with >>> 1024 DH Key and AES128 cipher. >>> >>> You can save your employer some money by grabbing the core RTP >>> H.235.6 encryption logic (using OpenSSL) straight out of h323plus. J >>> >>> But honestly implementing the H.323 signaling side of media >>> encryption >>> (H.235.x) is still going to be a nightmare as it touches everything. >>> H.225, H.245 (TCS and OLC) . There is DH Key matching/merging in >>> H.225, Cipher matching/merging in the H.245 TCS (on every >>> capability!) and that is just to generate the actual session key >>> encrypted in the OLC/OLCack which is of course different for each > RTP/RTCP media stream. >>> Simon >>> >>> *From:*Robert Jongbloed [mailto:ro...@vo...] >>> *Sent:* 11 July 2013 10:12 >>> *To:* Opa...@li... >>> *Subject:* Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 >>> >>> Well, I am committed to doing what my customer pays me to do! :-) >>> >>> They said they wanted SRTP for H.323, but I will check if that is >>> really the case. >>> >>> *Robert Jongbloed* >>> /OPAL/OpenH323/PTLib Architect and Co-founder./ Commercial support >>> at http://www.voxlucida.com.au >>> >>> On 11/07/2013 10:06 AM, Simon Horne wrote: >>> >>> Robert >>> >>> Yes that is correct. While H.235.8 is defined there is NO SRTP >>> deployed in H.323. H.235.6 is "native" and stenographic meaning it >>> uses standard RTP and only encrypts the payload and pads/truncates >>> the encrypted payload (multiple of key length) so it appears to >>> wireshark etc as being just plain regular RTP. >>> >>> You will need to committed to adding encryption in H.323 as >>> implementing H.235.6 is absolutely no simple undertaking and there >>> is no possible interworking function with SIP other than proxy >>> decrypt and re-encrypt. For instance we implemented in GnuGk the >>> H.323 side H.235.6 encrypt/decrypt function so it could sit in >>> front of the H.323/SIP border controller. >>> >>> Simon >>> >>> *From:*Robert Jongbloed [mailto:ro...@vo...] >>> *Sent:* 11 July 2013 09:04 >>> *To:* Opa...@li... >>> <mailto:Opa...@li...> >>> *Subject:* Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 >>> >>> So, you are saying the H.323 does not use SRTP at all? >>> >>> *Robert Jongbloed* >>> /OPAL/OpenH323/PTLib Architect and Co-founder./ >>> Commercial support at http://www.voxlucida.com.au >>> >>> On 10/07/2013 9:29 PM, Simon Horne wrote: >>> >>> Robert >>> >>> Nope. The universally agreed method in H.323 is H.235.6 (with >>> AES128,256) and this is what is deployed. >>> >>> While it was agreed, as I understand, at the time that >>> SRTP/H.235.8 for better interwork with SIP was going to be the >>> "way" of the future it just never happened. >>> >>> BTW: We agreed at the last ITU meeting to revise H.235.6 to >>> add 8k and 16k DH key length and more importantly to remove >>> the restrictive word "voice" out of the title to indicate it >>> is currently being deployed for both audio and video. >>> >>> Simon >>> >>> *From:*Robert Jongbloed [mailto:ro...@vo...] >>> *Sent:* 10 July 2013 18:44 >>> *To:* Opa...@li... >>> <mailto:Opa...@li...> >>> *Subject:* [Opalvoip-devel] H.235.8 - SRTP over H.323 >>> >>> Does anyone know of an endpoint that does SRTP over H.323, aka >>> H.235.8? >>> >>> >>> >>> -- >>> >>> *Robert Jongbloed* >>> /OPAL/OpenH323/PTLib Architect and Co-founder./ >>> Commercial support at http://www.voxlucida.com.au >>> > > -- > Jan Willamowius, ja...@wi..., http://www.gnugk.org/ > |