3 ms·

They can do this without keeping any meaningful information quite easily: They sign a client certificate with an expiry date at time of purchase using their CA

by hcrean 6y ago

They can do this without keeping any meaningful information quite easily: They sign a client certificate with an expiry date at time of purchase using their CA private key (that the court obviously can't force them to give up, HSM etcetera). Into the client certificate's DN or extended field they write the allocated public IP. The only information they need to store is that that IP is spoken for and not to be allocated again. They could also work this out on the fly. When the client comes to connect, they note that the certificate is signed and presented, and they route the public IP to the in-tunnel address of the peer, which they will have standardized to something meaningless like 10.0.0.2 As long as they don't log anywhere in the process, the signing of certificates means you don't have to remember the client at all.

mindslight 6y ago
The certificate approach has the advantage of the server storing nothing at all, but a standard username+password could accomplish something similar. It's not a big deal if the result of the query is a username and password. The central question is what type of records they kept for the payment.
- lstamour 6y ago
  Username and password doesn’t inherently have an HMAC+timestamp, so it has to be kept alongside payments. A certificate could be a one-time transaction, so the payment could be logged while the certificate is issued, the only worry after is if timestamps are present in the transaction method and timestamps are present (obviously) in the certificate, then correlation is still possible. Perhaps a workaround would be to take orders at any time but process orders in batches, where payment for all customers and certificate issuance for all customers happen at the same time/date. Or decouple certificate issuance from payment such that payment can occur any time and what is provided is a certificate that was previously generated/allocated at the start of the month or year. The downside to the preallocation is that the certificate private key would also have to be known in advance, it weakens security, but is perhaps an acceptable trade off for privacy. If transaction proof is possible, perhaps again with an hmac secret, you could provide proof of transaction at the start of the next month to keep the certificate issuance secure by presenting and issuing key material at a later date from when the transaction occurred. Actually, an hmac probably isn’t tamper-resistant enough given its value, unless you include a timestamp and correlate to transaction dates, or use a really long secret, or both and rotate the secret, perhaps. So you’d exchange payment for tokens, and tokens for certificates, decoupling the two. If your tokens are trusted, you could sell multi-year certificates or multiple tokens at the same time at the cost of reduced privacy if different features or timestamps are present in the tokens or transaction cost.
  - mindslight 6y ago
    > Username and password doesn’t inherently have an HMAC+timestamp, so it has to be kept alongside payments. I don't follow your logic here. A userdb record could simply consist of user+pass, service level, static public IP, and an expiration date - essentially the same information that a certificate would carry. The existence of a user record is certainly more legible to the legal system, and might help support a court order to actively surveil that "user's" activity. But from a technical perspective of what information can be gleaned here, they're the same.
    - lstamour 6y ago
      I don’t think we’re disagreeing? :) An expiration date and username is a type of payment record?
      - mindslight 6y ago
        I was referring to a payment record as something that would be useful to follow a trail, such as a cc auth# or transaction IP address.
kyran_adept 6y ago
Your method is probably the best you can do. I think the security firm claims, that while the tunnel is up, there is a connection - actual TCP connection, or UDP stream - that associates the client IP to the socket in the VPN infrastructure. If you could intercept that data and track it inside their infra, you could discover what IP PirateBay has on their backend.
deleted 6y ago
[deleted]

by hcrean 6y ago

mindslight 6y ago

The certificate approach has the advantage of the server storing nothing at all, but a standard username+password could accomplish something similar. It's not a big deal if the result of the query is a username and password. The central question is what type of records they kept for the payment.

lstamour 6y ago
Username and password doesn’t inherently have an HMAC+timestamp, so it has to be kept alongside payments. A certificate could be a one-time transaction, so the payment could be logged while the certificate is issued, the only worry after is if timestamps are present in the transaction method and timestamps are present (obviously) in the certificate, then correlation is still possible. Perhaps a workaround would be to take orders at any time but process orders in batches, where payment for all customers and certificate issuance for all customers happen at the same time/date. Or decouple certificate issuance from payment such that payment can occur any time and what is provided is a certificate that was previously generated/allocated at the start of the month or year. The downside to the preallocation is that the certificate private key would also have to be known in advance, it weakens security, but is perhaps an acceptable trade off for privacy. If transaction proof is possible, perhaps again with an hmac secret, you could provide proof of transaction at the start of the next month to keep the certificate issuance secure by presenting and issuing key material at a later date from when the transaction occurred. Actually, an hmac probably isn’t tamper-resistant enough given its value, unless you include a timestamp and correlate to transaction dates, or use a really long secret, or both and rotate the secret, perhaps. So you’d exchange payment for tokens, and tokens for certificates, decoupling the two. If your tokens are trusted, you could sell multi-year certificates or multiple tokens at the same time at the cost of reduced privacy if different features or timestamps are present in the tokens or transaction cost.
- mindslight 6y ago
  > Username and password doesn’t inherently have an HMAC+timestamp, so it has to be kept alongside payments. I don't follow your logic here. A userdb record could simply consist of user+pass, service level, static public IP, and an expiration date - essentially the same information that a certificate would carry. The existence of a user record is certainly more legible to the legal system, and might help support a court order to actively surveil that "user's" activity. But from a technical perspective of what information can be gleaned here, they're the same.
  - lstamour 6y ago
    I don’t think we’re disagreeing? :) An expiration date and username is a type of payment record?
    - mindslight 6y ago
      I was referring to a payment record as something that would be useful to follow a trail, such as a cc auth# or transaction IP address.

kyran_adept 6y ago

Your method is probably the best you can do. I think the security firm claims, that while the tunnel is up, there is a connection - actual TCP connection, or UDP stream - that associates the client IP to the socket in the VPN infrastructure. If you could intercept that data and track it inside their infra, you could discover what IP PirateBay has on their backend.

deleted 6y ago

[deleted]