The Omni Group
These forums are now read-only. Please visit our new forums to participate in discussion. A new account will be required to post in the new forums. For more info on the switch, see this post. Thank you!

Go Back   The Omni Group Forums > OmniWeb > OmniWeb Bug Reports
FAQ Members List Calendar Search Today's Posts Mark Forums Read

 
Cannot access https pages after installing Cisco VPN client Thread Tools Search this Thread Display Modes
Sorry for posting this again, especially since this is not an OW bug. But thus far I have not found any solution to this annoying problem. After installing a Cisco vpn client, I am no longer able to access https pages with any webkit browser (OW, Safari, Shiira). Camino and Firefox work fine, however.

I have tried uninstaling the vpn client manually (spotlight search) and through a sudo command in Terminal. It appears that the uninstall worked, but I'm still having problems with the browsers accessing https pages. Did all the other tricks as well. Still no luck.

Anyone else having issues?

Thanks.

PS It may not be the Cisco vpn client; others are having problems as well, especially after the latest security update. This bug makes OW impossible to use for secure sites. If anyone can offer any insights as to why WebKit browsers don't work but Gecko engines do, I would be most grateful.

Last edited by daiyi666@yahoo.com; 2006-12-02 at 11:56 AM..
 
Did you send in a bug report via Help->Feedback? This issue really sounds strange. The OW guys might be able to give you a hint on that if you send in logs.
 
Quote:
Originally Posted by zottel
Did you send in a bug report via Help->Feedback? This issue really sounds strange. The OW guys might be able to give you a hint on that if you send in logs.
Guess I should do this. It seems to be a WebKit issue, but not everyone is experiencing it either. On the Apple boards there are similar issues posted, too.
 
Finally found a solution. In case this is happening to others. Nice to have OW back full time.

http://discussions.apple.com/message...641899#3641899
 
I took a short look at this thread, and if I get it right, what's proposed there is turning off the validity checking for SSL certificates—which doesn't really sound like a good idea, IMHO. That means that your communication will still be encrypted, but you can't be sure that the site you are connected to is really the one it claims to be.

Ok, it's rather complicated to use this vulnerability for an attack. There'd be DNS spoofing involved, so the attacker would have to have access to a DNS server you use, or to the DNS server that holds the information about the spoofed-as site, or to your own /etc/hosts file. But it's a risk I wouldn't take, at least when online banking is involved.

What was the error you got when it didn't work? In the thread you linked to, someone said sth about a hostname mismatch—the certificate was issued for another hostname than the one he was actually connected to. I recently saw that the Apple Keychain shows this error even if there is only a case mismatch in the certificate—e.g. if the certificate was issued for www.MySpace.com, but the server identifies itself as www.myspace.com.

Wasn't there a thread here some time ago about OW turning all hostnames into lowercase to make URL spoofing harder? (Like using a capital i as an L—the host www.googie.com with the i capitalied—www.googIe.com—will look like www.google.com (GOOGLE, not GOOGIE) in most sansserif fonts.) Might that be the source of the problem?

Last edited by zottel; 2006-12-04 at 01:22 PM..
 
Quote:
Originally Posted by zottel
I took a short look at this thread, and if I get it right, what's proposed there is turning off the validity checking for SSL certificates—which doesn't really sound like a good idea, IMHO. That means that your communication will still be encrypted, but you can't be sure that the site you are connected to is really the one it claims to be.

Ok, it's rather complicated to use this vulnerability for an attack. There'd be DNS spoofing involved, so the attacker would have to have access to a DNS server you use, or to the DNS server that holds the information about the spoofed-as site, or to your own /etc/hosts file. But it's a risk I wouldn't take, at least when online banking is involved.

What was the error you got when it didn't work? In the thread you linked to, someone said sth about a hostname mismatch—the certificate was issued for another hostname than the one he was actually connected to. I recently saw that the Apple Keychain shows this error even if there is only a case mismatch in the certificate—e.g. if the certificate was issued for www.MySpace.com, but the server identifies itself as www.myspace.com.

Wasn't there a thread here some time ago about OW turning all hostnames into lowercase to make URL spoofing harder? (Like using a capital i as an L—the host www.googie.com with the i capitalied—www.googIe.com—will look like www.google.com (GOOGLE, not GOOGIE) in most sansserif fonts.) Might that be the source of the problem?

You raise many important concerns here--ones that I was wondering about myself. If I go to sites already bookmarked, however, won't that be safe? In other words, as long as I don't click on links provided elsewhere, it should be safe, no?

I would be interested in figuring out why this suddenly occurred. Others using Safari experienced the same problem. But thus far no OW users have posted here about the issue.

Thanks.
 
To be honest—I don't know myself how the validation protocols are named, so I don't know what the steps proposed in that thread actually do. It just sounds as if they turned off checking the validity of a certificate.

If that's what they do, though, bookmarks will not protect you against an attack. They will only protect you against the URL spoofing I mentioned later in the posting above.

This is what an attack might look like: The attackers hack the DNS server that is responsible for the bank's domain. They replace the bank's DNS records by their own. From that point on, the hostname www.bankxy.com will resolve to an IP address that points to the attackers' servers instead of to the servers of the bank. If you now enter that hostname in your browser (or click on the bookmark), and you ISP's DNS doesn't give you a cached result, but has to fetch the IP address from the domain's DNS server, your browser will show the attackers' site, not the bank's. The attackers have copied the complete banking interface of the bank and can collect PINs and TANs. Another way would be if your ISP's DNS server is hacked so it will give you only "cached" results for www.bankxy.com that have been inserted by the attackers. Or, if they gained root access to your computer, they could insert a line for www.bankxy.com in the file /etc/hosts—the system will not fetch the IP from a DNS server, then, but use the entry in /etc/hosts.

Now, if everything is configured as it should be, the following happens when an SSL session is started: The server sends its SSL cerificate to the browser, and the browser checks back if the certificate is correctly signed by the issuer of the certificate (like VeriSign). This is what you might turn off with the steps from the thread. If an attack is going on, you will normally be presented a warning by your browser and can take the appropriate steps. You won't see any difference with that checking turned off, though.

So, as you see above, it is _very_ difficult to launch such an attack. The money that could be earned might make this effort worthwhile in the case of a bank, though. Additionally, if you use HBCI (at least in Germany that's a standard where banking security isn't done via PIN/TAN, but with a smartcard and a reader attached to the computer) or your bank has a good TAN system (that randomly chooses a _numbered_ TAN you have to enter instead using one TAN after the other as they appear on the list), there couldn't be much harm done. The attackers could get you PIN and look into your account, but the could not send money anywhere else, as they can't know what the next TAN that's asked for will be, or, in the case of HBCI, wouldn't be able to get any information at all. And, another point is: It would probably be a better idea for the attackers not to use SSL at all—who will check if the little lock is present in his browser before entering sensitive data? So, maybe these settings wouldn't make any difference at all as SSL isn't used, ayway. Maybe.

Thus, that risk isn't _that_ great. But still a one I wouldn't take.

Last edited by zottel; 2006-12-04 at 02:51 PM..
 
There is a post today at macosxhints that addresses the problem—with a solution that sounds much better. :-)

http://www.macosxhints.com/article.p...61202123501700
 
Quote:
Originally Posted by zottel
There is a post today at macosxhints that addresses the problem—with a solution that sounds much better. :-)

http://www.macosxhints.com/article.p...61202123501700
Thanks. Basically I've been going between OW and Camino, which at times can be a bit of a hassle.
 
Strange. Removing the plist file does not work for me. Back to turning off the certificate authentication through Keychain.

Hope Apple gets this fixed soon! Back to two browsers again.

Thanks for the hint though; it must be working for others.
 
 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
Pages export? [A: Pro exports to the .docx format, which Pages can import.] teamnoir OmniOutliner 3 for Mac 2 2011-12-08 08:49 PM
Crash using https on BingoDisk success2be OmniFocus for iPhone 0 2008-08-18 10:41 AM
Bingodisk, WebDav, and SSL/HTTPS kingsinger Other WebDAV 1 2008-08-12 06:03 PM
Cisco WAN Link ahbe OmniGraffle Extras 3 2008-03-27 09:11 AM
VPN and https problems daiyi666@yahoo.com OmniWeb General 2 2006-12-03 11:03 PM


All times are GMT -8. The time now is 06:03 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.