You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I fully understand that using anything other than standard TLS/SSL would make
it easier for the protocol to be fingerprinted and potentially blocked.
FOrtunately, another project with a completely different aim has already worked
on the idea of transporting unreliable message-based protocols efficiently on
top of reliable stream-based protocols including TLS/SSL, without making it
possible to dinstinguish such behavior by means other than traffic flow
analysis. I recommend looking at http://dedis.cs.yale.edu/2009/tng/ -
especially their paper "Minion: Unordered Delivery Wire-Compatible with TCP and
TLS" and the drafts "Improving OpenSSL to Process Out of Order Data" and
"Unordered Delivery in TLS-Encrypted Connections".
Original issue reported on code.google.com by [email protected] on 6 Mar 2012 at 7:06
The text was updated successfully, but these errors were encountered:
I will note, however, that there may still end up being problems with this
since you will end up with doubled congestion control, which behaves... badly.
DTLS is really the only way to solve that, asd it *is* distingushable from
standard TLS.
A potential solution may be to adopt the TNG architecture more throughly, which
could provide other benefits. It's a rather neat concept, and the main reason
it is unlikely to be widely deployed on the public internet is due to legacy
concerns, which are less of an issue here.
Original issue reported on code.google.com by
[email protected]
on 6 Mar 2012 at 7:06The text was updated successfully, but these errors were encountered: