About the DTLS issue, I've opened a ticket on the tracker: https://bugzilla.mozilla.org/show_bug.cgi?id=828027
I'm not security expert but Wireshark shows the "server hello", "certificate" and "server hello Done" as a single UDP packet (pkt #337 in the pcap file). I thought each part is like an attribute and could be stacked as they contain "length" field. For the fingerprint, I know that the checking is up to the application itself (not done by OpenSSL) but what happens if we ask OpenSSL to verify the certs using "SSL_set_verify(ssl, (SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, .)" ? On Tuesday, January 8, 2013 10:40:50 PM UTC+1, Eric Rescorla wrote: > On Tue, Jan 8, 2013 at 10:33 AM, Mamadou Diop <[email protected]> wrote: > > > > > > > > I'm using Nightly 20.0a1 on Windows Vista and 8. The issues are: > > > > > > 1) The RTP profile for audio and video medias are not correct. Firefox > > > uses "RTP/SAVPF" instead of "UDP/TLS/RTP/SAVPF". > > > > > > > We're aware of this, but it's low priority. You'll need to fix it in the > > SDP for now. > > > > > > > > > 2) Both "window.mozRTCSessionDescription" and > > > "window.RTCSessionDescription" are defined but any attempt to create an SDP > > > with "window.RTCSessionDescription" fails. > > > > > > > Yes, don't use the second one. > > > > > > > > > 3) The initial SDP created using PeerConnection::createOffer() or > > > PeerConnection::createAnswer() contains all ICE candidates (not an issue of > > > course) and I guess this is why "onicecandidate" callback is never called. > > > The problem is that there is no way to known if ICE gathering is finished > > > or not. When using XMPP this is not a problem as it's possible to send > > > candidates alone but with SIP this is not allowed. > > > > > > > File a bug and we'll add a dummy call. In the meantime, of course > > you can just simulate the callback conditionally on you being > > Firefox (you need a polyfill in any case to handle prefixing). > > > > > > > > > 4) Firefox fails to recover from ICE role conflict when it has lower > > > priority. > > > > > > > Hmm... This code is supposed to work, but that doesn't mean there > > isn't a defect. If you can set logging to high using the following > > environment > > variables: > > > > R_LOG_LEVEL=9 > > R_LOG_DESTINATION=stderr > > > > And then file a bug with the ICE output, we can investigate. > > > > > > > > > 5) In response to the DTLSv1 hello message from my SIP gateway to Firefox, > > > I receive an error (Level: Fatal, Description: Bad Certificate). I'm sure > > > that certificates are correct, they are used for both HTTPS and WSS (off > > > course not only why I say it's correct). > > > > > > > I'd need to know more about what you are doing here. DTLSv1 hello messages > > don't contain > > certificates at all, so at this point the server should be sending a > > CertificateRequest > > message to you and shouldn't have seen your certificate yet. Note, however, > > that > > the test for whether a certificate is valid in this context is whether it > > matches the digests > > provided in the handshake, not whether it is valid for HTTPS. > > > > > > > > > 6) ...to be continued > > > > > > I also want to patch some other issue in Firefox. Where could I found the > > > source code to rebuild firefox? > > > > > > https://developer.mozilla.org/en-US/docs/Developer_Guide/Source_Code/Mercurial > > > > -Ekr _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
