Re: duplicate SSL record in different TCP packets from a Google Drive client
On Mon, November 5, 2012 10:12 am, Peter Djalaliev wrote: Hello, There seems to be a possible problem with the SSL implementation used in Google Drive on MacOS 10.8.2. I seems that this SSL implementation is NSS - please let me know if you know that Google Drive uses a different SSL implementation and I should direct this question elsewhere. Packet captures of SSL flows between the Google Drive client application and the Google servers it talks to show the following possible problem. During the application data phase of the TLS connection, the Google Drive client sends two consecutive TCP packets with different TCP sequence numbers, both containing the same encrypted SSL record. The cipher suite used is TLS_RSA_WITH_AES_128_CBC_SHA. A normal SSL server talking to Google drive will likely fail to decrypt the duplicated SSL record and verify its MAC, because AES decryption is used in CBC mode, and the duplicated SSL record should have a different SSL sequence number. However, it looks like the flow proceeds just fine. Can anybody here comment on this behavior? Is there a better place to ask this question? Best Regards, Peter Djalaleiv -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto Hi Peter, To the best of my knowledge, Google Drive for Mac (the desktop sync client) does not use NSS. A better forum for continuing the discussion and reporting the issue will likely be at http://productforums.google.com/forum/#!forum/drive -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
NSS Support for Encrypting File Attachments
Hello, Currently, does Mozilla NSS support encrypting of file attachments? Since it can encrypt email messages, I suppose, it can also support encrypting of file attachments? Is there an API available that can take advantage of encrypting file attachments using NSS? Btw, will the next release of Thunderbird 17 include the NSS 3.14 library? Thank you. Regards, Brian Teh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS Support for Encrypting File Attachments
On Tue, 2012-11-06 at 22:19 +0800, tehhzstar wrote: Hello, Currently, does Mozilla NSS support encrypting of file attachments? Since it can encrypt email messages, I suppose, it can also support encrypting of file attachments? NSS supports encryption. Regarding email attachments, NSS supports CMS (RFC 3852) which is used in encrypted/signed S/MIME emails. Usually, if all text and all attachments of an email are combined into a single grouped message (according to MIME standards), and the result is encrypted. The work to group multiple pieces into a single MIME message is a job done by an application, and after this step, you can use NSS to encrypt it. Is there an API available that can take advantage of encrypting file attachments using NSS? I don't think so, in addition to using NSS, your application should use a MIME library to prepare the input message for the encryption operation. Btw, will the next release of Thunderbird 17 include the NSS 3.14 library? Thank you. Unlikely, I'm afraid NSS 3.14 got released too late for the Mozilla release process. Here are the versions of NSPR/NSS currently being used by the various Mozilla release branches: https://kuix.de/mozilla/versions/ But given that Mozilla 17 will be an Extended-Support-Release (maintained for enterprise consumers for one year), it would be good if the Mozilla 17 branch eventually picks up NSS 3.14 in one of its scheduled security fix releases (17.0.x). I can't promise it, but it seems likely. In any case, if you decide to build your own local copy of Thunderbird 17.x, it should work just fine to build against the newer NSS library. Regards Kai smime.p7s Description: S/MIME cryptographic signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
