|
||||
I can't make any direct recommendations. Since you asked about OpenBSD, and this is in an OpenBSD subforum, here's a link to a recent discussion about providers who offer OpenBSD hosting, from the misc@ mailing list:
The thread starts here: ==> http://marc.info/?l=openbsd-misc&m=123533998914160&w=2 Note: OpenBSD is not a requirement for any of these VPN or encrypted-proxy technologies. |
|
|||
Thank you all for the assistance. Now I'll just look around those services posted in that thread.
|
|
||||
I'm not so sure HTTPS is the appropriate answer for keeping communications private, Danno.
HTTPS is fine when you don't care if someone knows *which* bank you do business with. If you care to keep that information private, then it's the wrong medium. (This also means you want to use a bank that doesn't put your account numbers in the URLs, even if they use HTTPS. Unless you don't care about that, either. ) |
|
||||
Respectfully, I think you're making arguments where there may be none- I agree with your points from the perspective in which you make them. My perspective was of the information contained within communications, not the obfuscation of some kind of the communications themselves. I may have not been clear.
I offer this analogy- You may understandably not want traffic cameras at toll booths snapping shots of the interior of your car, but are you going to avoid taking the toll road altogether because they're going to possibly take a snapshot of you passing the toll booth itself? On the use of HTTPS, I thought it to be (and still do) sufficiently widespread for the types of communications the OP was referring to- banking, email, etc. NOT, for instance... this site . The lack of widespread HTTPS adoption is not HTTPS' fault- it's a fault of your local handyman webmaster . Lastly, and again respectfully, if your bank is sending your account numbers in the URL's of your online communications... tis' time to get a new bank. And fast.
__________________
Network Firefighter Last edited by ai-danno; 10th March 2009 at 05:54 AM. |
|
|||
Got another quick question about my situation.
Regarding man-in-the-middle attacks with like ARP poisoning or something else I'm not aware of (Since I'm still new to all this); would it be plausible for an attacker to obtain the login credentials to the server I ssh to? Or log in via some other method besides web? I read that this was possible even when someone logs in with https. |
|
||||
As we've discussed, only the data portion of HTTPS packets are encrypted. Everything else about them are plain-Jane TCP, with its own security issues. TCP has been subject to spoofed-packet attacks, for many years. See the ClientAliveCountMax and TCPKeepAlive sections in sshd_config(5) for a short description of TCP's limitations.
It is unfortunate, but there are some ...er...uhm... extremely popular operating systems which do not bother to randomize the Initial Sequence Numbers (ISNs) used during TCP session creation even though it is accepted knowledge that a priori knowledge makes TCP spoofing/injection/MitM attacks easier to deploy. See this discussion of modulate state in the PF User's Guide, for one way OpenBSD routers can provide those workstations and servers with a little bit of protection from themselves.For SSL and TLS encryption and authentication, which may be used with HTTPS, there are varying crytographic methods that may be selected by the administrator when using either technology, and varying authentications that may be used, from complex end-to-end keys and certifications to none-at-all. Can the various SSL or TLS cryptographic systems be broken? Maybe. Depending on how things are configured, poor authentication makes the crypto choice moot.You've once again raised broad concerns, without specifics. You're going to have to get specific with your question(s) if you want any kind of specific answers. Last edited by jggimi; 15th March 2009 at 12:37 AM. |
|
||||
I think the breakdown is that https/ssl is used for logins on websites where the subsequent traffic will be https/ssl (in most cases, anyway. If you do happen upon a site that authenticates you 'in the clear' (via regular http) look for an explanation as to why, or don't surf there any more thinking you're secure.)
So what jggimi's saying is that it's not simply or specifically your authentication credentials that are risk, but all potentially all transmissions. And he's right. However, as I've mentioned on this subject in other threads in the past, I don't feel that this is likely to happen, or happen with any regularity. Put bluntly, MITM attacks are exotic and rare, and require a position in the path of traffic. The idea of MITM attacks are normally for very specific incidents of highly anticipated traffic- in other words, a person conducting a MITM attack would have to anticipate a site you might surf to, have a full mock-up for the sign-in section of that site, and then wait and redirect (or copy and pass) that intended traffic to the mock-up to steal your information. If they were actually impersonating the sites (phishing) and not just doing a "copy and pass" of the traffic, they would also have to redirect any ssl certificate verification traffic to mock-ups of those verification sites, so that ssl certificate checks to the bogus sites would be approved by your browser. While the attacker waited for those sites to be called up, they would have to not redirect all other traffic (or re-redirect it lol) so you wouldn't think anything's wrong. That's pretty involved, and would involve a compromised or otherwise malicious network device in the path of your traffic to that particular site. That's a really low probability (albeit increased very significantly with unencrypted wireless connections.) Aside from unencrypted wireless considerations, I would say as a network/security administrator that your potential weak points of security lie less in the paths of communication for endpoints, and more in the endpoints themselves. Your home LAN, the bank's servers, or the insurance company's database- these are the places where the vast majority of breaches of security take place. So be careful who you communicate with, and be sure your own house is in order. Oh, and don't do your banking at while sipping a latte at Starbucks
__________________
Network Firefighter Last edited by ai-danno; 15th March 2009 at 06:11 AM. Reason: it's copy and pass, not pass and copy! |
|
||||
An open, unsecured WiFi access point is a great example of a place where VPN technologies can add security. Even the sshd(8) daemon in it's default configuration can be used as a secure, tunnelled SOCKS proxy for a client web browser at the local Internet cafe.
|
|
||||
Quote:
__________________
UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. |
|
||||
hehehe, no, no ... I'm happy with the site... and it's administration.
One of the reasons I like it, in fact, is because it's not private and therefore not needing of the encryption used for things like banking sites. It's open for the community to take advantage of, and I'm quite thankful for that.
__________________
Network Firefighter |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
DSL Router | Zvrk | NetBSD General | 1 | 18th June 2009 01:21 PM |
Good router | terryd | General software and network | 10 | 9th February 2009 09:31 PM |
D-link (DI-524) router | c0mrade | General software and network | 3 | 26th January 2009 08:14 AM |
Router shopping | Yuka | General Hardware | 8 | 23rd July 2008 02:51 AM |
Router for external IP's | bichumo | General software and network | 11 | 22nd July 2008 03:07 AM |