If you're talking about Moxie's "sslstrip" attack, it's more of a user-oriented attack than an actual technical attack on SSL. It doesn't break the underlying cryptography or trust model. (He has another tool, sslsniff, which actually does attack some of the technical implementations of trust and certificate checking.)
First of all, you should watch his Defcon presentation on sslstrip, if you haven't already: http://www.thoughtcrime.org/software/sslstrip/. If nothing else, it's a great insight into how reason about security flaws.
The origin of sslstrip was based on a simple observation: most users don't arrive at SSL sites by directly typing in the URL or typing a bookmarked https:// URL. Most users connect to a non-SSL site and get redirected (e.g. HTTP 302 redirect), or they connect to a non-SSL site that has a link to the SSL site and they click the link.
In either case, the non-SSL site can easily be man-in-the-middled, and therefore the URL that the user is redirected to can be silently modified by an attacker. E.g. your link to https://bankofamerica.com/ can be changed to https://firstname.lastname@example.org/. The end users still sees a padlock and a valid certificate, it just happens to a certificate for www.badguy.com instead of bankofamerica.com. Moxie also showed some other cool stuff with unicode in URLs and finding glyphs that look like forward slashes in order to further deceive the end user, but that stuff has since been fixed in most browsers and is ancillary to the root cause of the problem.
To answer your questions:
No certificates are compromised in this attack, so "strength" doesn't matter at all. All certificates used are completely valid in a cryptographic sense.
You don't have to own the local router. You can use an ARP spoofing attack to man-in-the-middle your target if you are on the same network as them.