(untitled)

Lainchan, no onion address why? I can provide hidden service with port forwarding if needed.

This might have been a better post for /q/. My understanding of onion addresses is that that they don't provide the user any more privacy or security than if the user had otherwise been using tor.

Only benefit from using hidden service versus normal site, is protection from evil exits. But of course with https the threat of evil exits should be also really limited.

https rely on certificate authority bundle which means you trust who builds the bundle and who is in the bundle. onion addresses rely on noone but the two parties. with https the domain name is rememberable and neither the authority nor the certificate is usually verified by the user. with onion address getting and verifying the correct address is comparable as if the user were forced to verify the certificate, many times this will not be done in practice but if done once it can be reused a lot of times, https would need be verified each time.

>> 19533 this was asked more than once before Appleman promised to post some decision log but in the end it wasn't posted I want lainchan to have onion address If there is an explanation I would like to know

I could run hidden service entry for lainchan, but of course it wouldn't be official in that case. I'm running similar gateways for bunch of services, which mostly block official exits. It's just Tor hidden service and Nginx proxy_pass under the hood, relaying traffic from web to onion. For security tin foilers it's of course totally heretic solution.

>>19565 >https rely on certificate authority bundle which means you trust who builds the bundle and who is in the bundle. Not exactly. With HTTPS you rely on the security of the weakest CA because in the event of a man-in-the-middle attack, it would only take one invalidly-issued certificate from one (any) CA to succeed, regardless of the validity of the legitimate certificate on the actual website. To understand certificates with any level of clarity, first you need to understand asymmetric cryptography: > Each party generates public/private key pair > public key encrypts > private key decrypts > (but you can do this backwards on a hash of something and call it a 'signature') So you can send someone your public key, and some information 'signed' by your private key, and the receiving party can verify that the provided public key matches the signature on the other data. That way they know the sender has access to the private key which coupled with the public key and with the extra data. A response to the extra data can then be encrypted with the provided public key, and only the original sender will be able to read it. A certificate signing request works like this (somewhat simplified) > Server generates public/private keypair and makes a Certificate Signing Request (CSR) > CSR contains the server's public key and some extra information (like domain name) > Certificate Authority (CA) receives CSR, verifies that the signature on the extra data with the domain name > CA now performs some validation stems to ensure that the server which sent the CSR really is in control of the domain (add a DNS record, add a webpage, phone calls, etc) > There are also Extended Validation (EV) certificates which validate not only technical control of the domain but also the legal entity which owns it > Having approved the CSR, the CA issues a certificate which basically stamps the the CSR with some additional parameters like the CA's name or restrictions on use, then signs it with its own private key > The Server gets the signed certificate, which clients can validate because Microsoft or Debian or Apple has pre-installed many different Certificate Authority public keys > If you get to a website and there is no certificate error, the idea is that both you and the server can 'prove' that your communication is totally secure to eavesdroppers and hasn't been tampered with. The huge problem with this is that, except for certain niche and unpopular practices such as Certificate Pinning, the whole system is only as secure as the weakest CA is insecure. The legitimate website might get a certificate through a very reputable CA, but it only takes one certificate from the worst and least secure CA to render that moot for an attacker trying to intercept or change data. In other words, the danger isn't that your CA will tamper with your CSR somehow, it's that the different CA altogether will fraudulently issue a certificate purporting to be from you.

I think encouraging tor posting is a bad idea. Honestly, it's a miracle this board isn't a soykafheap.

>>11095 Mean tor poster IQ is 115. We are masterrace, and extremely literate in many various subjects relevant to this board

>>11096 Lovely post, .onion user