From: Allen <net...@so...> - 2009-12-22 18:36:52
|
Hi Robert, You are absolutely right about it being only 40 bit that was cracked. There is also a 56 bit version out there as well. 56 bit DES was cracked ages ago. So for the moment if an installation is actually 128 bit it is safe, more or less, from brute force, but the RSA part may be good for only a few years at most according to Lenstra back in 2008 when they worked on the 307 bit prime factor. The site, Blue Crypt, http://www.keylength.com/en is worth poking around in to see what different people think is safe and for how long. Best, Allen Robert Kennedy wrote: > You really have to take this article with a grain of salt. > > First, SSL is NOT only 128 bit, it could be 40 bit. (The key recovered > in 1995 was a 40 bit key) > > Second, the article talks about cracking 40 bit SSL. NOT the much more > common 128-bit SSL found today. And yes, brute force attacks on 40-bit > crypto is practical with today's computers. > > Third, to my knowledge it is NOT practical to crack 128 bit SSL even > for the NSA with their super computers. > > Forth, if is was easy to crack 128-bit SSL, you would have heard about > it all over the Net. > > If you want to make sure you are using 128 bit SSL (and not 40 bit SSL) > check the Certificate provided to your wen browser. All modern websites > use 128 bit SSL. > > I am not saying that one day it will be practical to crack SSL by brute > force (especially if you believe in Moore's law). But we are not there > yet. We are a long way to go. > > Rob > > > > Date: Mon, 21 Dec 2009 14:19:25 -0500 > Subject: Re: TightVNC vs TeamViewer > From: joh...@wo... > To: net...@so... > CC: al...@ix...; sb...@ka...; > vnc...@li... > > Eeeeeekkkkkk!!!!!!! > > On Mon, Dec 21, 2009 at 12:24 PM, Allen <net...@so... > <mailto:net...@so...>> wrote: > > Hi John, > > (Picture very red face here!) Sorry to say it is even worse than I > said, alas. SSL was brute force cracked and the encryption key > recovered in 1995 by a bank of 112 ordinary desktops in 32 hours. > > Excellent article about this from 2004 at: > > http://www.marktaw.com/technology/HowlongdoesittaketocrackS.html > > At that time the peak super computer speed was 70 teraflops and > could crack the SSL encryption key in 7 minutes by one computer > according to rough figures. Currently the peak is almost 3 petaflops > so about 40 times faster. > > One can assume that while NSA, etc., probably don't have the fastest > out there I'd bet they have a lot of capability. I'd guess that it > probably takes less than 1 minute for them to crack SSL. > > Since SSL is only 128 bits this could be done by even small > organizations because, after all, a couple of years ago $2500 would > buy almost 30 gigaflops and 6 months later, August 2007, it was down > to $1300 or < $50/gigaflop! (Let's see, Moore's Law, and it is 28 > months since then, I'd guess < $20/gigaflop today.) > > There is another problem I wasn't aware of until I started looking > closer and that is not all servers may be set up with 128 bit SSL, > there are also 40 and 56 bit versions that might still be being > used. Given the security assessments I've done and how badly > organizations have done being up to date to current standards, I > would not be all surprised to find some of the older ones still in > place. > > So, for practical purposes SSL is *very* dead. Probably the only > thing protecting it in reality is the amount of SSL traffic to and > from banks, etc., that finding yours would be finding a needle in a > haystack. > > SSH anyone? Well, according to RFC4253 SSH only SHOULD use 128 bits > or more. > > http://www.ietf.org/rfc/rfc4253.txt > > We are going to have to look very carefully at all of this as new > and better cracks are coming along every day. > > Happy Holidays to all, > > > Allen > > > john s wolter wrote: > > Allen, > > Oh rats. > > > On Sun, Dec 20, 2009 at 3:54 PM, Allen > <net...@so... > <mailto:net...@so...> > <mailto:net...@so... > <mailto:net...@so...>>> wrote: > > Yes, SSL has been cracked but it is quite tricky to do as I > understand it. The real problem is that the data can be captured, > stored and the SSL crack applied. Basically it is not primarily a > crack of SSL but the creation of a rouge certificate > authority then > using a colliding certificates attack. > > "The vulnerability exploits a bug in the MD5 cryptographic > hashing > algorithm used to create some of the digital certificates > published > by certification authority (CA). The crack works because > hashes are > used to create a digital “fingerprint” that is supposed to > uniquely > identify a document and can easily be calculated to verify > that the > document hasn’t been modified in transit. But the flaw in the MD5 > algorithm makes it possible to create two different documents > that > have the same numerical hash value." > > From: > > > http://www.mydigitallife.info/2009/01/01/researchers-crack-ssl-by-phishing-and-spoofing-digital-certification-authority-ca/ > > Pretty good overview. > > Well, we know that certificates can be forged and duplicate ones > created by bit fiddling an embedded PDF file. So the real > issue is > connecting and staying with SSL. This is the key problem with > something like echoServer. If SSL was used through an echoServer, > but then the server dropped out of the loop after the initial > connection was made to facilitate creating a direct machine to > machine connection - using another protocol for encryption > and key > sharing via a challenge-response (with an asymmetric > public/private > encryption was used) so that no actual password was on the > network - > then SSL would be good enough for the initialization, at > least for a > while longer. > > Doing the key exchange this way and creating an direct tunnel > avoids > most of the problems associated with certificates. Yeah, I know, > somebody will find a hole in this thinking big enough to > swallow the > Titanic sooner or later. ;-> > > Best to All, > > Allen > > john s wolter wrote: > > Scott, > > One more unfortunate item is that I was just told by > colleague > under certain circumstances SSL can be cracked. Total > bummer. I have not cracked it myself yet but I'm going > to track down his > statements. > TLS appears to be beyond this problem but I wonder how widely > available and supported it is. > > More cheers in this case. > > On Sun, Dec 20, 2009 at 2:06 PM, john s wolter > <joh...@wo... > <mailto:joh...@wo...> > <mailto:joh...@wo... > <mailto:joh...@wo...>> > <mailto:joh...@wo... > <mailto:joh...@wo...> > > <mailto:joh...@wo... > <mailto:joh...@wo...>>>> wrote: > > Scott, > > Thank you for responding, I'll take a look at it to > see how it > works. The only concern is the echoServer not being > GPL'd if I > understand what you had to say about it. > > Cheers. > > > On Sun, Dec 20, 2009 at 1:27 PM, Scott C. Best > <sb...@ka... <mailto:sb...@ka...> > <mailto:sb...@ka... <mailto:sb...@ka...>> > <mailto:sb...@ka... <mailto:sb...@ka...> > <mailto:sb...@ka... <mailto:sb...@ka...>>>> wrote: > > John: > > Hello! I built a VNC-based system similar to > TeamViewer, that > can be configured to work directly with TightVNC. > It's called > EchoVNC, > and works like this: > > 1. Install EchoVNC on your TightVNC Server. EchoVNC by > default comes > with its own VNC service (we built our from the > UltraVNC distro), > but one of the configuration options lets you > work with > an already > running VNC service. We also have a "zero config" > version of the > VNC server called InstantVNC, in case you just > want to > email > something to a remote user that's not running > VNC yet. > > 2. Install EchoVNC on your TightVNC Viewer. Again, > EchoVNC has it's > own VNC Viewer application, but it can be > configured to > work with > another platform's viewer. > > 3. On both sides of the connection, login to the same > echoServer. > Think of that application as a "relay server" > similar > to what > the TeamViewer service provides. In this setup, the > echoServer is > the only piece that requires firewall or NAT > configuration. A > static IP address for the echoServer is useful, > but a > dynDNS > addrees also works. Once both sides (Viewer and > Server) can > connect and login, they can connect to each other. > > Once that's all setup, start the EchoVNC > Viewer, > and it will > display a "point and click" list of remote clients you > can kick off > a TightVNC Viewer session with. Also, the "tunnel" > created between > the Viewer and Server and the echoServer during > the VNC > session is > SSL-secured. > > Everything except the the echoServer (a > shareware > download > available for Linux and Windows) is VNC-based, so > all of > those > pieces > are GPL'd open-source. More details here: > > http://www.echogent.com/download_echovnc.htm > > Hope this helps, and I welcome any > suggestions for > improvement. > > cheers, > Scott > > > > john s wolter wrote: > > The main obstacle I have in using > TightVNC more > widely is the > setup with remote customers. It requires that > I make > a site > visit and > deal with all the routers and firewalls. > Wouldn't it > be nice > if combined > with SSL or TLS and other ToDo items if a > remote setup > facility could be > created for TightVNC. > > I've just used TeamViewer with a > customer and > was able to > install with the customer's help during a simple > telephone > conversation. > > TeamViewer is an VNC like package which > uses it > online servers > to setup and help conduct remote sessions. > TeamViewer has a > download > which installs its client-server software used > during a > remote session. > Their servers handle tasks like session > authentication and > access > control. It was a very straight forward process. > > Both parties in a remote session are > TeamVieiwer > members and > have loaded their software onto the users > computers. > Needed > passwords > are communicated via telephone or IM session > for remote > sign-on and are > different for every sign-on. > > TeamViewer does not have any need to > setup the > router > in a > NAT'ized network, i.e. no port forwarding setup is > required. > TeamViewer's software and online session > manager handles > everything > needed to start a remote connection. I do not > know but I > would guess > that after a remote connection is established > the online > session manager > is not needed. > > I image an online hosted session service to > perform > sessions > setups would be a possible approach. It > would help > do the > remote setup > and configure a route or port at the start of each > session. > This would > be a separate software piece of this puzzle. > > Any thoughts? > > Cheers. > > > ------------------------------------------------------------ > John S. Wolter President > Wolter Works > > > > > > -- > ------------------------------------------------------------ > John S. Wolter President > Wolter Works > Mailto:joh...@wo... > <mailto:joh...@wo...> > <mailto:joh...@wo... > <mailto:joh...@wo...>> > <mailto:joh...@wo... > <mailto:joh...@wo...> > <mailto:joh...@wo... > <mailto:joh...@wo...>>> > > > Desk;1-734-665-1263 > Cell: 1-734-904-8433 > > - Internet & IT Infrastructure Design & Build > - Innovation in Product Design, Tradeoffs, Business > consulting > - Internet Business, Marketing, Design, Virtualization > - Engineered Systems Integrations > - Software Development & Embedded Systems > > Introduce us to new customers and earn rewards > > > > > -- > ------------------------------------------------------------ > John S. Wolter President > Wolter Works > Mailto:joh...@wo... > <mailto:joh...@wo...> > <mailto:joh...@wo... > <mailto:joh...@wo...>> > <mailto:joh...@wo... > <mailto:joh...@wo...> > <mailto:joh...@wo... > <mailto:joh...@wo...>>> > > > Desk;1-734-665-1263 > Cell: 1-734-904-8433 > > - Internet & IT Infrastructure Design & Build > - Innovation in Product Design, Tradeoffs, Business > consulting > - Internet Business, Marketing, Design, Virtualization > - Engineered Systems Integrations > - Software Development & Embedded Systems > > Introduce us to new customers and earn rewards > > > > ------------------------------------------------------------------------ > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer > Community > Take advantage of Verizon's best-in-class app development > support > A streamlined, 14 day to market process makes app > distribution > fast and easy > Join now and get one step closer to millions of Verizon > customers > http://p.sf.net/sfu/verizon-dev2dev > > > ------------------------------------------------------------------------ > > ___________________________________________________________ > TightVNC mailing list, > VNC...@li... > <mailto:VNC...@li...> > <mailto:VNC...@li... > <mailto:VNC...@li...>> > > To change your subscription or to UNSUBSCRIBE, please visit > https://lists.sourceforge.net/lists/listinfo/vnc-tight-list > > > > > -- > ------------------------------------------------------------ > John S. Wolter President > Wolter Works > Mailto:joh...@wo... > <mailto:joh...@wo...> > <mailto:joh...@wo... > <mailto:joh...@wo...>> > > Desk;1-734-665-1263 > Cell: 1-734-904-8433 > > - Internet & IT Infrastructure Design & Build > - Innovation in Product Design, Tradeoffs, Business consulting > - Internet Business, Marketing, Design, Virtualization > - Engineered Systems Integrations > - Software Development & Embedded Systems > > Introduce us to new customers and earn rewards > > > > > -- > ------------------------------------------------------------ > John S. Wolter President > Wolter Works > Mailto:joh...@wo... <mailto:joh...@wo...> > > Desk;1-734-665-1263 > Cell: 1-734-904-8433 > > - Internet & IT Infrastructure Design & Build > - Innovation in Product Design, Tradeoffs, Business consulting > - Internet Business, Marketing, Design, Virtualization > - Engineered Systems Integrations > - Software Development & Embedded Systems > > Introduce us to new customers and earn rewards > > > Windows Live: Keep your friends up to date with what you do online. > <http://go.microsoft.com/?linkid=9691810> |