I am trying to figure out how Signal messenger audio/video encryption works.
I have read the blog post
https://signal.org/blog/signal-video-calls-beta/
and the RFC for DTLS-SRTP
https://tools.ietf.org/html/rfc5764
what I don't understand is how the DTLS handshake is actually made.
My first question is where does it feed the initial certificates does it uses the identity keys for both parties to negotiate the TLS session ?
It uses webrtc for android, with eliptic curves, and looking into the source code I can see it uses, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA or if compiled with boringssl TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. So any ideea how is compiled ? The sources for webrtc, where it works with the encryption algorithms are in
https://chromium.googlesource.com/external/webrtc/+/5647a2cf3db888195c928a1259d98f72f6ecbc15/webrtc/base/opensslstreamadapter.cc.
Thank you.
Related
Currently the TLS Session Resumption documentation for Node.js only covers two methods (Session IDs and Session Tickets) both of which are obsoleted in the TLS 1.3 spec. In practice I've found that Filezilla is not utilizing either of these methods over TLS 1.3 when the server is configured to handle them.
That was confirmed to me by a Filezilla team member, they only utilize the Pre-Shared Key method as specified in TLS 1.3.
Which brought me to the PSK docs, which are sadly even more sparse and dated than the session resumption docs. They don't even cover exchanging a PSK during the handshake and instead focus on out of band PSK. I've been digging through the Node source but am not finding anything very helpful since most of this stuff is in the deps -> OpenSSL and my skills at deciphering C are not great.
It is quite possible that my question is not suitable for this medium, if so I understand if it is closed. That said, my question is simply: Can PSK based session resumption be achieved in Node.js at all at this point and if so, what would that flow look like?
There are ice-ufrag and ice-pwd parameters in SDP, but do they (or any other parameters) really need be private for secure end-to-end connection if I can ensure SDP offer/answer was not modified (with digital signature as an example)?
The use case is P2P system where I have a public key of the other side and want to ensure I'm actually securely connected to it. The other side however doesn't have my public key and doesn't care who am I.
WebRTC and related specs are too large so that I didn't find clear answer to this question yet (HTTPS is recommended everywhere, but not much besides that), also I haven't found any article that considers WebRTC security from this point of view. Hopefully someone with deep WebRTC knowledge can clarify this question.
Questions that this one was marked as possible duplicates of do not include any proof of the SDP origin (in form of digital signature or in some other way), which is why this question is in unique.
Absolutely! While WebRTC secures its data communication, the SDP is a free ticket to call you.
If you don't secure your signaling channel then you may end up having a perfectly secure call with an attacker, who unbeknownst to you forwards packets to and from your intended call recipient.
This is a variant of Man-in-the-middle attack. See security.stackexchange.com for more.
I'm struggling for a long time. I need to create secure channel from Desktop App to JavaCard. I found GlobalPlatform http://www.win.tue.nl/pinpasjc/docs/apis/gp22/ but I can't get it working. I know how to react when I have a secure channel ( use it ) but strugling to create it. I know I should create Key on my desktop app then somehow send InitUpdate APDU, then create ExtAuth APDU and then it should work? I know I'm lost so if anybody have some example or something I'll be so glad!
(Assuming you want to implement the client-side of the communication)
The SCP protocols used to establish secure channel are precisely defined in GlobalPlatform Card Specifications,
available here, specifically:
SCP01 / SCP02 / SCP10 in GlobalPlatform Card Specification v2.3 (appendices D,E,F)
SCP03 in Card Technology Secure Channel Protocol '03' Card Specification v2.2 – Amendment D V1.1.1
You can have a look at GlobalPlatformPro (java) or GPShell (C) for some source code.
Good luck!
PS: The org.globalplatform API you mention in your post is used inside the card and allows javacard applets to use keys stored in the SD for secure communication/authentication.
Is it possible to have every message signed with digital signature in XMPP (Jabber) protocol? By this I mean not channel encryption over SSL/TLS but exact signing of each message.
Yes, in the sense that there are several standards, including https://datatracker.ietf.org/doc/html/draft-miller-xmpp-e2e, which nobody that I know of has implemented yet, but is liable to be the best starting point.\
No, in the sense that even if your client implemented that protocol, not all of your friends would us it, so "every" is not achievable.
For a program I am writing, I would like to use TLS (or something similar) to encapsulate my application's protocol. This will minimize both the amount of work I have to do as well as the number of vulnerabilities I could accidentally create.
My program is designed to be peer-to-peer although one or more servers provide some services to help one user locate another (it registers IP address/port combos) but do little else. I want to make this system very fault-tolerant so having these servers act as a Certificate Authority is unacceptable because a compromise of a server or its key would affect too many users. Therefore I plan on using a Web of Trust.
The main problem with using TLS is that the original TLS 1.2 specification (RFC 5246) does not provide for using OpenPGP certificates. It seems to be very x.509 centric. RFC 6091, which obsoletes RFC 5081 and extends RFC 5246, makes provisions for an extension to TLS that does what I want. The problem is that I don't think BouncyCastle implements this extension and I can't find a Java crypto library that does. I also don't want to write my own / contribute to BC because I'm really bad at not making mistakes and I'm also very lazy.
Another problem with this is that BouncyCastle provides "a light weight client-side TLS API" but because this software is P2P, a server-side API is also necessary so that I can use TLS by making it believe that the peer originating the connection is the client. I'm pretty sure that once the handshake is complete that it's the same.
Questions:
Is there any way that I can still use TLS (which I highly doubt)? Is there a protocol like TLS that is designed for P2P, or at least can function in this way (like I believe TLS can), but can work with an OpenPGP certificate? If neither is the case, should I pursue the idea explained in this question and implement my own layer taking concepts from TLS?
Links to RFCs: RFC 5246 and RFC 6091
The only library that I know to support RFC 6091 (i.e. TLS with openpgp certificates) is GnuTLS but I don't know whether you can use something like that in Java. Alternatively you could replicate the SSH semantics, where you store the public keys of your peers using self-signed
X.509 certificates.
In TLS, the X.509 parts are actually handled as opaque blobs:
The server sends its certificate (and some helper certificates, if it wishes so) as (a list of) opaque string(s) of bytes (a three-byte length, followed by the encoded certificate as arbitrary bytes).
When the server asks for public key client authentication, it sends a list of "names" which are supposed to be the encoded X.500 names of the root CA the server will recognize -- there again, opaque blobs (two-byte length).
The client, when (if) it sends a certificate (chain), uses the same format than the server.
As TLS is defined, both client and server are supposed to use the peer public key, which they get in any way they see fit and that's mostly out of scope of the TLS specification: the certificates exchanged over the wire are considered as mere helpers. So there would be no problem in actually sending OpenPGP encoded public keys in those blobs, as long as both client and server expect it -- and since you control code on both, this should be no issue.
Your problem then "simply" becomes a matter of making a TLS implementation accept to hand you the blobs without choking on them. I know of no existing Java-only TLS implementation which will fit the bill, so you may have to write a bit of code -- but I urge you not to fiddle with TLS protocol details except processing of the certificate blobs. Those things are subtle and weaknesses are sooo easy to create...
As far as I know, the Sun/Oracle JSSE implementation only deals with X.509 TrustManagers (which you can customize to handle certain extensions, but would still expect a structurally valid X.509 certificate.
It might be possible to use Java's security API to implement RFC 6091, but I'm not sure how. It's definitely more work than just tweaking the TrustManagers, as you would have to go deeper into Java's implementation of TLS.
Alternatively, if it's for a bespoke server, you could re-use the key material from PGP certificates into X.509 certificates and put the initial PGP certificate (with all its signatures) as a blob in a custom X.509 extension (as it's more or less done here). The problem here would be interoperability, since such an extension wouldn't be a standard. Implementing a TrustManager in Java that is able to understand extension is definitely feasible, and you wouldn't need to dig into the internals of Java's TLS stack, you'd only have to deal with custom TrustManagers to initialize your SSLContexts.