First look at Psiphon
Some screen shots:
1. Main server control window

2. User log-in through browser

3. Browsing with Psiphon

4. SSL certificate of Psiphon

Overall, I find Psiphon easy to set up and quite handy for personal use on a Windows PC. However, I do have one specific concern over the SSL certificate used by Psiphon. As shown in the screen shot above, Psiphon uses "somename.somewhere.com" as the common name in its SSL certificate.(Psiphon source code is not published at the time of writing.) So if someone wants to block all Psiphon traffic, all he needs to do is to block SSL traffic when a SSL certificate's common name is "somename.somewhere.com". I hope Psiphon developers will use randomized SSL certificates in the next release.
Update:
Canuck at Psiphon forum posted instruction to change server SSL certificate
1. Main server control window

2. User log-in through browser

3. Browsing with Psiphon

4. SSL certificate of Psiphon

Overall, I find Psiphon easy to set up and quite handy for personal use on a Windows PC. However, I do have one specific concern over the SSL certificate used by Psiphon. As shown in the screen shot above, Psiphon uses "somename.somewhere.com" as the common name in its SSL certificate.(Psiphon source code is not published at the time of writing.) So if someone wants to block all Psiphon traffic, all he needs to do is to block SSL traffic when a SSL certificate's common name is "somename.somewhere.com". I hope Psiphon developers will use randomized SSL certificates in the next release.
Update:
Canuck at Psiphon forum posted instruction to change server SSL certificate
1. Delete key.pem and cert.pem.
2. Edit openssl (looks like a shortcut in windows because it has a .cnf extension that doesn't show in Windows Explorer.) using notepad. You can change all the fields such as country name, common name, etc.
3. When you save it, ensure you just click save so as not to put .txt in the end (easily fixable if you forget)
4. When you restart Psiphon, it will regenerate the key and certificate to be used based on the fields in the openssl.cnf file.
Labels: Proxy Services
I'd like your opinion on this too :
http://psiphon.civisec.org/forum/viewtopic.php?t=114
Posted by
Anonymous |
8:52 AM
Too easy. Just use two nodes in a row.
Log in to node B, then to node C before surfing to Site D. We can probably do this right now manually. Somebody please try it and see if you can surf through one node to use another and finally to some place like WikiPedia. I'd try it right now, but an existing bug in the first (unnumbered?) version is keeping me offline today.
Chaining nodes automatically on an admin-admin cooperative basis is an obvious next step. Assign a username and password to a psiphonode instead of a person and let it connect through whenever a user logs in. Each node admin can then build up an ad-hoc list of second-hop nodes to connect through, along with names and paswords for each, and the node can use whichever one it wants.
As the community grows and deepens, such cooperative efforts between admins will become common.
Keeping it manually controlled by admins (which nodes to chain with) would probably avoid a lot of complexity and problems as well, keeping it easy to program, easy to operate, and easy to fix when an admin makes a mistake. Full automation of this kind of chaining could create all kinds of entertainment when the occasional bug creeps in. ;]
I think we can call this a good feature request for upcoming versions. It's simple enough to implement for even novice admins, once the capability is added.
Let's make sure we find a way to automatically limit a chain to two or three hops though. Overall bandwidth averaged across all nodes increases with the number of hops allowed. Gnutella developers could tell you all about the effect, which is why the 7-hop flat structure of the original gnutella 0.4 protocol has become a 3-hop two-tiered structure in today's gnutella 0.6.
Posted by
Anonymous |
10:50 AM