profile
viewpoint

radfish/pyelliptic 2

Python OpenSSL wrapper for ECC (ECDSA, ECIES), AES, HMAC, Blowfish, ... (BitMessage fork)

radfish/monero-core-git-PKGBUILD 1

PKGBUILD for official GUI for Monero digital currency

radfish/BitcoinUnlimited 0

Bitcoin Unlimited continues on gitlab see https://gitlab.com/bitcoinunlimited/BCHUnlimited

radfish/bitmonero-git-PKGBUILD 0

Arch Linux package for bitmonerod (forked from AUR)

radfish/dat-gateway 0

In-memory Dat to HTTP gateway

radfish/Flexget 0

The official FlexGet repository

radfish/gostcoin 0

GOST R 34.11-2012 algo, GOST R 34.10-2012 signature

radfish/i2pd 0

Full C++ implementation of I2P client

radfish/linux-mainline-kernel 0

Linux kernel source tree

PullRequestEvent

PR closed namecoin/ncprop279

Travis: Remove x509-signature-splice

It's been replaced by SpliceSigner.

+2 -9

1 comment

1 changed file

JeremyRand

pr closed time in 10 days

pull request commentnamecoin/ncprop279

Travis: Remove x509-signature-splice

Triggering a rebuild...

JeremyRand

comment created time in 10 days

PR opened namecoin/ncprop279

Travis: Remove x509-signature-splice

It's been replaced by SpliceSigner.

+0 -8

0 comment

1 changed file

pr created time in 13 days

issue openednamecoin/StemNS

Optionally resist fingerprinting

Tor Browser instances that use StemNS are vulnerable to fingerprinting, because a website can probe for StemNS-based eTLD's via subresource loading. This is arguably not a huge deal, since each supported naming system only adds 1 bit of fingerprintability. It is also arguably not a huge deal because we intend to make Namecoin support the default. However, IMO it's still a problem that we should fix, especially during the transitional period where Namecoin support isn't ubiquitous.

Tor Browser exposes the first-party eTLD+1 via the SOCKS username. We can thus resist fingerprinting like this:

  1. If the SOCKS username eTLD matches the destination eTLD, resolve via Prop279 like we do now.
  2. If the SOCKS username eTLD does not match the destination eTLD, leak the resolution to the exit relay (as though StemNS were not active).

This will prevent websites from fingerprinting StemNS-based eTLD's via subresource loading. It will not prevent websites from fingerprinting StemNS-based eTLD's via first-party redirects, but that's outside of Tor Browser's threat model anyway. It will cause some security degradation, in that websites with a DNS-based first-party domain who access subresources on Namecoin will be vulnerable to hijacking of those subresources by malicious exit relays.

Note that we do not simply return a resolution error in case 2, because that would be fingerprintable based on the delay taken for an error to happen while loading the subresource.

It should be noted that the .bit.onion eTLD will not have any security degradation from this, because Tor will see it as an invalid .onion domain, and not leak it to an exit relay. It should also be noted that .bit domains with TLS enabled will not be hijackable unless the exit relay is colluding with a compromised TLS CA, and ncp11 is not installed in Tor Browser. .bit domains that resolve via an IP address without TLS are vulnerable to hijacking either way, so that's not really a problem. The major source of security degradation is .bit domains that resolve via an onion service without TLS. I tend to think that the "right" way to handle this is to encourage usage of TLS with .bit domains, even when onion services are used (or else make it clear that .bit domains that resolve via non-TLS onion services should not be used as subresources of first-party non-.bit domains).

This behavior should be optional. Some users may prefer to never leak resolution to an exit relay, even if it makes fingerprinting easier.

created time in 17 days

MemberEvent

PR closed MirakelX/mirakel-android

Update README.md invalid
+1 -1

0 comment

1 changed file

sohamgit

pr closed time in 2 months

created tagnamecoin/StemNS

tagv0.1.1

Port of TorNS to Stem

created time in 2 months

create barnchnamecoin/StemNS

branch : 0.1

created branch time in 2 months

push eventnamecoin/StemNS

Jeremy Rand

commit sha 864fff871314abe03d03d5c06a89f32efd6ab5ab

Safely close stream if a service fails to launch Closing the stream allows the user to promptly see an error message instead of waiting to timeout.

view details

push time in 2 months

push eventnamecoin/StemNS

Jeremy Rand

commit sha ee61cb4c35d6f9c6b39c21679836bccf59148649

Fix flake8 warning

view details

push time in 2 months

push eventnamecoin/StemNS

Jeremy Rand

commit sha b5b72bf87683041f9948f39cb38d6e8dbe2d8d53

Improve debug logging

view details

Jeremy Rand

commit sha f5ac0f2b4bbf6cf23a12e42362e5bfb35ae04bbc

Handle service launch failure more safely If no service is configured, we don't need to log the failure at all (the failure is expected). If a service *is* configured but failed to launch, don't attach the stream (doing so is unsafe since it will leak Namecoin resolution to the exit relay).

view details

Jeremy Rand

commit sha 2f6c577194a8010aad522a02c32d0c4cb8af9d61

Suppress noisy logging In the future, we can make this logging configurable, but right now it's just in the way.

view details

push time in 2 months

more