If you want to translate Dvorak to/from Qwerty, go snag this decrypt script I wrote a long time ago. It's NOT what was used for the chapter. (You'd know why if you read the chapter.)
The quick way to switch your actual keyboard is to use setxkbmap, or loadkeys, but if then you'd need to type in all the comments here to have them translate. This script would work as a filter, which is more convienient.
Also, if you want to switch back and forth, or are on an old system that doesn't have alternate keyboards available in X11, I use tod/toq, from the Tools section of Hacking Linux Exposed website.
If you're wondering why there aren't many posts by the other authors, that's because they're all in or recovering from Las Vegas....
The second edition was written by James Lee. He was not involved with the first edition, so he had the choice of reusing the original material, or rewriting/augmenting where he felt that was more appropriate. In the end, James ended up rewriting far more often than not, and it really shows - the book is an excellent book, and a huge improvement over the original.
This article originally showed "James Loo" as the author, and that has now been corrected, so this thread can die now. Lee. Not Loo.
Full Disclosure: James and I worked on Hacking Linux Exposed together, and he's a damned fine chap and killer Perl guru. He's the one who badgered me into learning Perl years back, and I don't thank him nearly often enough for it.
I can tell you there are many many dvorak keyboard users out there. I accidentally registered aoeu.com (the dvorak equivalent of asdf.com) when debugging a DNS register program for an ISP. The amount of email it'd get if it weren't blocked is astounding.
Actually, there was someone who videotaped my SSH talk. It was in Haskel 108, so it may well be that he recorded others as well. If anyone has details, I'd love to know if its available.
But yes, wish there was a centralized site for all the presentations, since you could only attend 5-6.
The email sent to the fest list, and the main linuxnorthwest.org page says to go to (and post to) the Presentation section of the LFNW message board. There are about 4 of the presentations linked there thus far, hopefully the other presenters will follow suit as well. No doubt many people are still recovering from a long long Saturday night, and like to incorporate any changes/updates before posting the presentations online.
Bad plan. Now, the next time you log into a new machine you'll think that rm will be safe and will wipe out an entire directory tree again.
If you want to have a safe alias, use a different name! For example del would be appropriate. If you're not good enough to use rm correctly, then an old DOS command seems appropriate...
And never use a VPN when....
on
SSH or IPSec?
·
· Score: 3, Insightful
Never use a VPN when a single SSH or SSL connection will do.
SSH can tunnel any number of ports along with the actual login stream, so you could have multiple ports on your local box that get tunneled through the secure connection. Say your SSH session terminates (through a firewall) to a box on the corporate LAN, and you tunnel IMAP, MySQL, and Squid. Point mutt and mysql to localhost, and point your browser to localhost as a proxy. Voila - you have secure access, no special software required.
Stunnel can do the same thing, and is often faster because it only does the tunneling, and it doesn't need to transmit them all within the same single connection. Stunnel 4.x can handle multiple ports in separate threads like magic. End result though is that you can map the ports/services you actually require, and only those bits are open. Yes, it's not a VPN (unless you want PPP over SSH/SSL, see my comment below), but in most cases you don't need one.
(Weird coincidence: I'll be giving a talk wednesday at real world linux about this very topic, and will be putting up the presentation when I get back. If anyone else is braving SARS in Toronto, stop by and say hi.)
Yes TCP over TCP not good, but not bad.
on
SSH or IPSec?
·
· Score: 4, Informative
No, it is definitely a problem. Eventually, over a slow link that drops packets, the TCP over TCP problem results in increasing retransmit times, which can slow things down. However you can usually stop/start the VPN again very quickly (run a script out of cron that checks ping response times) and you won't loose the existing connections (though they will hang for a while, obviously.)
Over stable links, you're unlikely to have a problem though.
PPP over SSH/SSL/etc
on
SSH or IPSec?
·
· Score: 4, Informative
PPP (I haven't used PPPoE) over SSH or SSL/TLS (Stunnel) works like a charm. The problem is correctly configuring the authentication (you want to have both machines authenticate the other) and locking it down (you don't want the user to be able to do *anything* except create the network connection) and automating the route additions and any other changes (easiest to handle via ppp's up/down script support.)
I've written up step-by-step instructions and scripts that will do the whole durned thing, no brain required, that are in Building Linux VPNs, but was unable to convince NewRiders that one of these chapters should be the one put online. (Instead they picked chapter 1 which, while fine, doesn't provide any instantly-usable information for someone trying to actually build a VPN.
There are a few examples on stunnel.org for setting one up with Stunnel (3.x). You may also want to learn how to correctly use and restrict passwordelss SSH ability here including using authprogs to restrict commands. (You do use command="",no-port-forwarding,no-x11-forwarding,no -agent-forwarding,from="" in all your.ssh/authorized_keys don't you? )
Eventually, the TCP over TCP factor will kick in, and your VPN will be slow. But with a simple ping timer, you can kill/restart connections pretty painlessly via cron.
Plus, no kernel recompilation is required.
Re:Forget driving - take the Pogo Linux Busses
on
Linuxfest Northwest
·
· Score: 1
Why yes, the signup has passed. I checked to see if it was still open when I posted -- guess they must have filled up between my post and this evening. I don't remember when the official signup cutoff was supposed to be.
Sorry if I got folks' hopes up.
Irony: giving out free OSS/etc at the Fest
on
Linuxfest Northwest
·
· Score: 3, Interesting
You want irony? We're going to be near the belly of the beast, and we're going to have all sorts of open source / free software related freebies and raffles. I know of at least the following:
Bill Wright (aka the "Hunter Gatherer Penguin") is the main raffle/freebie/swag organizer, and has some books donated by O'Reilly, as well as who knows what else.
I've gotten about 40 books (security, perl, linux, web dev, etc) from McGraw-Hill, Addison-Wesley, NewRiders, and Sams, as well as a few copies of EnGarde Linux by Guardian Digital, and possibly some swag from Gibraltar Software. I'll also have some of my books for raffle/signing/etc.
Jeremy Reed of ReedMedia will be giving out a boatload of FreeBSD cds. Or maybe that was NetBSD cds. I forget.
But, for the real irony, Lee Fisher will be providing some Microsoft.NET development CDs at the LinuxFest.
There will undoubtably be plenty of freebies at the booths and presentations, so if you want to come and can't justify it to yourself, just think of it as a free Open Source swag shopping spree.
Forget driving - take the Pogo Linux Busses
on
Linuxfest Northwest
·
· Score: 1
I live in Seattle, so Bellingham isn't as far as for those Oregonians. (Did I get that right?) However, following one of the three rules for all good perl developers, I plan to exhibit my laziness in full form.
PogoLinux is sponsoring two busses for the trip, which will be leaving North Seattle Community Colloge (the place where GSLUG meets)
and heading up to Bellingham the morning of the fest. To sign up, go to their signup page. I believe we'll be watching "RevolutionOS" on the trip, plus you get to extend your geeky day by being surrounded by linux and open source advocates for 3 hours of fun in addition to the fest. And you don't need to do the driving. What could be better than that?
I'll be putting the slides from my "Linux: The Securable Operating System" presentation online after the show. I believe that Crispin Cowan will be putting his online as well. He's doing a fun one about how WireX's Immunix box handled Defcon's capture the flag.
I'd imagine lots of these will be online somewhere. We'll probably link to them from the linuxnorthwest.com page.
Amusing - I don't think I've been quoted in a slashdot comment before. Weird feeling.
The dorm was at Northwestern University, back when I was in undergrad there. I don't know who wrote up the 'contest' (it was typed, so we wouldn't even have been able to compare handwriting had we a suspect) but I know that several people copied down some of the username/passwords from the list to try out. Someone (possibly the one who created the contest, but who knows) made a copy of some of the entries available on IRC (I forget where, this was a while ago.)
Anyway, I compared the login times and IP addresses for the usernames that were on the list, and they were coming from all over heck. No fancy programming was used, just 'who' output plus some lame shell scripts sufficed.
I believe that the administrators heard about the list and locked out all accounts that had published their passwords, so that stopped it. Individuals needed to go back in person to get their passwords reset, and they probably learned not to be so gullable any more.
If anyone is going to the Northwest Regional Linux Fest in Bellingham, Washington, I'll be giving out some copies of OSWB that the publisher sent me for that purpose. I'd be happy to
sign them. Since I took my job as a tech editor a bit further than most, there are sentances, occasionally whole paragraphs of this book that were written by me. I even put in jokes now and then.
Luckily, James and Brent replaced my attempts at humour with stuff that was funny.
Lee and Ware do cover these issues. Persistant database connections, user authentication methods (both in Apache and in CGI/mod_perl/etc), caching (how it affects 'scripting' languages, etc), proper way to create user sessions with cookies, templates (as used in WML mostly). Even though it's an intro level book, they cover many issues that are often explained poorly or burried in other books.
The whole goal of this book was to explain how to do things the right way. Unlike most other LAMP books, they do cover these issues, and do so with security and proper coding/software architecture techniques in mind.
If there is such a book out there, then let me know, because I have not seen one.
You haven't read OSWB - go get it and see what you think after actually reading it.
So by all means, go out and buy bunches of copies of Open Source Web Development with LAMP and help the
Electronic Frontier Foundation at the same time. Or, if you don't like to buy online, go to your favorite
book store and buy it there, and send any money you saved on shipping to the EFF yourself.
I was one of the tech reviewers of OSWB. James and Brent wrote the thing in LaTeX, the lucky bastards,
so I was able to see the whole thing as it unfolded, updated nightly via CVS over SSH.
Now you might call me biased -- James and I have worked together for almost a decade now, and he's
the one who badgered me into learning Perl way back when. And he's got a great pull out couch that my
daugter and I sleep on when we go back to Evanston for Northwestern Homecoming every year.
I got a free signed copy, but that's the only way I benefit -- OSWB sales don't affect my
pocketbook in any way.
So, with those disclaimers out of the way, here is my review of OSWB.
Open Source Development with LAMP is the perfect book to learn a wide variety of server
technologies that will have you writing useful, clean, fast, and productive websites
before you finish reading it.
I was one of the technical editors of this book, and was able to watch it evolve as
they wrote. The authors have made a huge effort to make the book appropriate for
multiple Linux distributions, and they have achieved the highest degree of technical accuracy.
OSWB covers many different technologies, some complementary, some discreet. By showing you
many of the possible tools, this book lets you decide which is best for the job at hand.
The theory behind OSWB is that knowledge of 20% of a tool's capabilities will let you
accomplish 80% of the tasks you face. OSWB does a superb job of giving the user a sizable
introduction to webserver technologies that will be sufficient for most rojects, and tells
you where you can get information for advanced needs. They have written their entire website
with the exact same tools they teach you in the book, and they offer the entire source of their
website for download for your investigation and reference, as well as all the samples and
projects in the book itself.
The gold in this book is not just the descriptions of how the languages work, but how you can
use them singly or together to create interactive websites. Their are many sample projects
which let you see how everything fits together, and much of the ode can be adapted immediately
to your needs. The book is extremely well integrated and organized.
I have used some of the languages described in this book, while others were completely new to
me. I am definitely not a web design person, preferring to write back-end server software.
However while reading OSWB, I was charged with creating a MySQL database with a customizable web
interface for my alumni organization. Using only this book and a few perldoc commands, I was able
to create an interactive mod_perl website in a few days.
This book offers something to everyone, even advanced web designers. If you are starting out in
Web technologies, or are curious about other ways you can get the job done, this is the book for you.
Robin Gross, previously the staff attourney at the Electronic Frontier Foundation has founded a new group named IPJustice. I suspect it's still getting it's feet since it's so new, but it will hopefully be able to do to IP abuses what the EFF does for online/free speech/etc issues.
No, I never assume the public has a brain. Your comments are completely correct. However I was addressing a vulnerability in SSL and HTTPS in particular, rather than a vulnerability of the user sitting in front of their computer.
SSL is not immune to man in the middle attacks. Where did you get that?!? Any public key system is vulnerable during the first key exchange.
Bull pucky.
SSL is not vulnerable to a MITM during key exchange as you describe iff you are verifying certificates. HTTPS, as implemented in web browsers and other software that includes a list of trusted certificate authorities (CAs) does verify certificates. Not only that, but it requires that the common name (CN) match the host name, to prevent me (I have a cert for ssl.example.com) from interposing myself between a client and your server (www.some_domain.com) with my valid CA-signed ssl.example.com certificate.
Now if you use a client that does not support certificate verification, then yes, you are vulnerable to a MITM. For example when you use SSH and connect to a host for the first time and do not already have a copy of the host key stored on your machine (perhaps you got it on a floppy, loaded it from a web page, or some other method of getting it that you trust) then you must blindly say "Yes, I trust this fingerprint is correct." If you do this, then you may have been MITM'd, and you wouldn't know.
The best bet in this case is to check the actual server certificate once you log in and make sure that it matches the one you just accepted. You'd need to "cd/etc/ssh; cat ssh_host*.pub" and compare the output of the server keys to the one just entered into your ~/.ssh/known_hosts file. True, if you were MITM'd, then the cracker could be re-writing the keys you read from your cat command, but that's a pretty high bar for it to get over. (You might run 'less' or 'more', etc, so it's difficult for it to know when you're viewing the actual server key.)
So, in summation, if your use of SSL (or any public-key crypto) doesn't include certificate verification (or the appropriate analog), you are always vulnerable to a MITM attack. Major HTTPS implementations do not fall into this category.
Obviously you need to have a firewall that is available from the wireless network. Configure this machine to give out DHCP addresses so the wireless network is effectively in bridge mode.
When a machine joins the network and gets an IP address and attempts to hit a website, it will attempt to go through your firewall. You'll want to have this machine redirect the connection to a webserver on that machine that shows a "authenticate in some way, shape or form." Using whatever logic you want, it decides to allow this machine to go out the firewall unstopped. You could probably have this program write the IP address to a file or database or something.
Some other process picks up that there's a new machine that should be granted access, and it creates a new iptables rule to allow it unrestricted outbound access, thus bypassing the "redirect everyone to our 'authenticate' page".
Now the next issue is how to keep a new person from using this same IP address. You could watch for MAC address changes and remove the iptables rules if the MAC changes.
This is a bit hasty response - heading out the door.
The debate between using the best tool for the job, vs using the best Open Source equivalent is going to be around forever. Here are some of my completely random thoughts:
When you choose an Open Source project and it has deficiencies, you can talk with the developers to explain what needs fleshing out. If you can code, then you can work on this yourself. In the end, you help create a better product that may be more appropiate for a wider audience. It may be painful in the process, however.
When you are told you must have certain functionality that is not available in an Open Source product, make sure that the requirements are not artificial. When someone requires you have your document in some proprietary format, you can supply it in something open and they may never know the difference. Write your "Word Docs" in OpenOffice. Make your presentation in HTML and run it with a web browser. Question any requirements that seem to be based on the preconcieved notions of the requestor.
When functionality of an Open Source product is close but below its proprietary equivalent, do remember that "usability" is a factor of what you can do now, and what you can do later. The Open Source product will be available in it's current incarnation freely forever. (And later versions will likely continue to be developed as well.) The proprietary product may not be around tomorrow, it's license may change, or they may hold your work for ransom, and you have no control. You will likely find the product depricated forcing a costly upgrade at some point - that's the way the vendor continues to get income.
When you simply must have a given set of functionality that is not available with Open Source software, and you do not have the ability to work with developers to achieve it, use the proprietary product reluctantly. Stay abreast of changes to the Open Source products available. Do your best to keep as much available outside the proprietary application so you can extract it and put it into something Open Source when available down the road.
I have a new Treo 300 with Sprint as the wireless telco. I got it for a few reasons:
Unlimited PCS (internet / sms / etc)
Free roaming within the Sprint areas
Free long dist
Treo has keyboard, no wasted grafiti space.
You get a real IP address when you connect, meaning any TCP/IP app should work.
After having this thing for a month, the things that are not as happy are:
Plan to be near a charger. This thing sucks batteries like mad when used as a phone (but not so much when using TCP/IP, oddly.) It comes with a car charger for a reason. Plan to plug it in every night.
The network (TCP/IP) seems to go down when you're not using it, so if you haven't done anything with it in a while you're going to need to manually tell it to disconnect before doing any browsing/etc. Learn the shortcuts to do this that are present in some apps
SMS is one way. You can receive two kinds of messsages. An actual SMS message results in you getting redirected to the web browser to check it, which doesn't seem to work for me ever. The other kind seems to work just fine. See my previous comments on their SMS support.
Handspring wants you to buy a separate SMS product to make it fully functional.
No email support by default. (Again, they have a separate product, Treo mail.)
Blazer browser is very slow when you go forward/back, as if it's rendering it each time even when cached. I'm looking into new options.
Every time you open the unit, it goes to the phone application.
The last one was a particular problem for me. One of the most pressing reasons to get this was to have ssh (using TopGun SSH) access from my phone in case of emergency, or just feeling the need to check my email with Mutt. If you closed the phone to pick up your daughter, your connection was dropped because you launched the phone when you opened it. I used Buttons-T to get around this by telling it to do nothing when the phone is opened, and no problems since then.
The unit is probably heavy if you're used to a sleek model (I wasn't) but I have no problems keeping it in my pocket around the house at night.
One aside: I've tried getting the TopGun SSH source, and can't seem to get the Login portions that it requires. Anyone know where I can get the complete source? Emailing the author(s) hasn't worked. I'd like to do a code audit to make sure it is correctly verifing host keys, which I suspect is is not.
Sprint seems to have two different message types.
The first is a "One Way Message" which is up to 160 characters. I've sent hundreds of these messages and haven't lost a single one yet. You can't reply to them, but you can have them tagged with a source phone number, making it easy for the recipient to call back.
The second type they have is the "PCS Short Mail Message". This is the one that claims compatibility with non-sprint customers, and is presumably the SMS message. I've probably had 20% of these dropped as I was testing. Now the real problem is that on my phone (Treo 300) you cannot read these messages, you need to click on the URL which sends you to the sprintpcs page, from which you must log in and read the message. This is annoying enough as it is, but the real problem is the fact that the sprintpcs page, for whatever reason, doesn't render on the phone itself. Sure, it works in Mozilla, but the point is to have them at your fingertips, not your desktop.
Sprint has a free web page where you can send the
"One Way Messages" so it doesn't cost a thing. It doesn't even require cookies or anything, so you could even automate it with a brain dead shell script.
I wanted to have a simple indication when I get new emails when I'm out and about, so I set up a procmail rule that pipes a copy of certain emails to a program email2pager. This program determines if it should send a message (time of day, if I'm active on the mail server, etc) and then scans the email for the Subject and From, then goes and grabs the first bit of the message (stripping MIME headers, "So and so said", commented text, remember, 160 characters max) and then sends it to a second perl script (misnamed sms-sprint) which uses LWP to connect to the Sprint page and send the message.
It works without sending the whole message to Sprint. Anything that is sensitive should have been sent with PGP, of course.
If anyone is interested in the scripts, let me know.
Slashdot Mirror
The quick way to switch your actual keyboard is to use setxkbmap, or loadkeys, but if then you'd need to type in all the comments here to have them translate. This script would work as a filter, which is more convienient.
Also, if you want to switch back and forth, or are on an old system that doesn't have alternate keyboards available in X11, I use tod/toq, from the Tools section of Hacking Linux Exposed website.
If you're wondering why there aren't many posts by the other authors, that's because they're all in or recovering from Las Vegas....
This article originally showed "James Loo" as the author, and that has now been corrected, so this thread can die now. Lee. Not Loo.
Full Disclosure: James and I worked on Hacking Linux Exposed together, and he's a damned fine chap and killer Perl guru. He's the one who badgered me into learning Perl years back, and I don't thank him nearly often enough for it.
I can tell you there are many many dvorak keyboard users out there. I accidentally registered aoeu.com (the dvorak equivalent of asdf.com) when debugging a DNS register program for an ISP. The amount of email it'd get if it weren't blocked is astounding.
Actually, there was someone who videotaped my SSH talk. It was in Haskel 108, so it may well be that he recorded others as well. If anyone has details, I'd love to know if its available.
The email sent to the fest list, and the main linuxnorthwest.org page says to go to (and post to) the Presentation section of the LFNW message board. There are about 4 of the presentations linked there thus far, hopefully the other presenters will follow suit as well. No doubt many people are still recovering from a long long Saturday night, and like to incorporate any changes/updates before posting the presentations online.
Bad plan. Now, the next time you log into a new machine you'll think that rm will be safe and will wipe out an entire directory tree again.
If you want to have a safe alias, use a different name! For example del would be appropriate. If you're not good enough to use rm correctly, then an old DOS command seems appropriate...
SSH can tunnel any number of ports along with the actual login stream, so you could have multiple ports on your local box that get tunneled through the secure connection. Say your SSH session terminates (through a firewall) to a box on the corporate LAN, and you tunnel IMAP, MySQL, and Squid. Point mutt and mysql to localhost, and point your browser to localhost as a proxy. Voila - you have secure access, no special software required.
Stunnel can do the same thing, and is often faster because it only does the tunneling, and it doesn't need to transmit them all within the same single connection. Stunnel 4.x can handle multiple ports in separate threads like magic. End result though is that you can map the ports/services you actually require, and only those bits are open. Yes, it's not a VPN (unless you want PPP over SSH/SSL, see my comment below), but in most cases you don't need one.
(Weird coincidence: I'll be giving a talk wednesday at real world linux about this very topic, and will be putting up the presentation when I get back. If anyone else is braving SARS in Toronto, stop by and say hi.)
Over stable links, you're unlikely to have a problem though.
I've written up step-by-step instructions and scripts that will do the whole durned thing, no brain required, that are in Building Linux VPNs, but was unable to convince NewRiders that one of these chapters should be the one put online. (Instead they picked chapter 1 which, while fine, doesn't provide any instantly-usable information for someone trying to actually build a VPN.
There are a few examples on stunnel.org for setting one up with Stunnel (3.x). You may also want to learn how to correctly use and restrict passwordelss SSH ability here including using authprogs to restrict commands. (You do use command="",no-port-forwarding,no-x11-forwarding,no -agent-forwarding,from="" in all your .ssh/authorized_keys don't you? )
Eventually, the TCP over TCP factor will kick in, and your VPN will be slow. But with a simple ping timer, you can kill/restart connections pretty painlessly via cron.
Plus, no kernel recompilation is required.
Sorry if I got folks' hopes up.
There will undoubtably be plenty of freebies at the booths and presentations, so if you want to come and can't justify it to yourself, just think of it as a free Open Source swag shopping spree.
PogoLinux is sponsoring two busses for the trip, which will be leaving North Seattle Community Colloge (the place where GSLUG meets) and heading up to Bellingham the morning of the fest. To sign up, go to their signup page. I believe we'll be watching "RevolutionOS" on the trip, plus you get to extend your geeky day by being surrounded by linux and open source advocates for 3 hours of fun in addition to the fest. And you don't need to do the driving. What could be better than that?
I'd imagine lots of these will be online somewhere. We'll probably link to them from the linuxnorthwest.com page.
The dorm was at Northwestern University, back when I was in undergrad there. I don't know who wrote up the 'contest' (it was typed, so we wouldn't even have been able to compare handwriting had we a suspect) but I know that several people copied down some of the username/passwords from the list to try out. Someone (possibly the one who created the contest, but who knows) made a copy of some of the entries available on IRC (I forget where, this was a while ago.)
Anyway, I compared the login times and IP addresses for the usernames that were on the list, and they were coming from all over heck. No fancy programming was used, just 'who' output plus some lame shell scripts sufficed.
I believe that the administrators heard about the list and locked out all accounts that had published their passwords, so that stopped it. Individuals needed to go back in person to get their passwords reset, and they probably learned not to be so gullable any more.
Luckily, James and Brent replaced my attempts at humour with stuff that was funny.
The whole goal of this book was to explain how to do things the right way. Unlike most other LAMP books, they do cover these issues, and do so with security and proper coding/software architecture techniques in mind.
If there is such a book out there, then let me know, because I have not seen one.
You haven't read OSWB - go get it and see what you think after actually reading it.
Yes, the Amazon and B&N links that are on OSWB uses the same HTML as the Hacking Linux Exposed books page (and the Building Linux VPNs books page too, since you're asking.)
So by all means, go out and buy bunches of copies of Open Source Web Development with LAMP and help the Electronic Frontier Foundation at the same time. Or, if you don't like to buy online, go to your favorite book store and buy it there, and send any money you saved on shipping to the EFF yourself.
So, with those disclaimers out of the way, here is my review of OSWB.
Open Source Development with LAMP is the perfect book to learn a wide variety of server technologies that will have you writing useful, clean, fast, and productive websites before you finish reading it.
I was one of the technical editors of this book, and was able to watch it evolve as they wrote. The authors have made a huge effort to make the book appropriate for multiple Linux distributions, and they have achieved the highest degree of technical accuracy.
OSWB covers many different technologies, some complementary, some discreet. By showing you many of the possible tools, this book lets you decide which is best for the job at hand.
The theory behind OSWB is that knowledge of 20% of a tool's capabilities will let you accomplish 80% of the tasks you face. OSWB does a superb job of giving the user a sizable introduction to webserver technologies that will be sufficient for most rojects, and tells you where you can get information for advanced needs. They have written their entire website with the exact same tools they teach you in the book, and they offer the entire source of their website for download for your investigation and reference, as well as all the samples and projects in the book itself.
The gold in this book is not just the descriptions of how the languages work, but how you can use them singly or together to create interactive websites. Their are many sample projects which let you see how everything fits together, and much of the ode can be adapted immediately to your needs. The book is extremely well integrated and organized.
I have used some of the languages described in this book, while others were completely new to me. I am definitely not a web design person, preferring to write back-end server software. However while reading OSWB, I was charged with creating a MySQL database with a customizable web interface for my alumni organization. Using only this book and a few perldoc commands, I was able to create an interactive mod_perl website in a few days.
This book offers something to everyone, even advanced web designers. If you are starting out in Web technologies, or are curious about other ways you can get the job done, this is the book for you.
Robin Gross, previously the staff attourney at the Electronic Frontier Foundation has founded a new group named IPJustice. I suspect it's still getting it's feet since it's so new, but it will hopefully be able to do to IP abuses what the EFF does for online/free speech/etc issues.
No, I never assume the public has a brain. Your comments are completely correct. However I was addressing a vulnerability in SSL and HTTPS in particular, rather than a vulnerability of the user sitting in front of their computer.
I've written many times about how blindly clicking "YES" is a great way to defeat your security. SSL is not a magic bullet, SSH MITM Attack "Challenge" writeup, and a good section in HLEv2 which is unfortunately not availble online. I'm sure you can find a few of my rants in the Stunnel mailing list archives as well.
Do I trust that users will possess a brain and use it? Hell no. But that wasn't the original question.
Bull pucky.
SSL is not vulnerable to a MITM during key exchange as you describe iff you are verifying certificates. HTTPS, as implemented in web browsers and other software that includes a list of trusted certificate authorities (CAs) does verify certificates. Not only that, but it requires that the common name (CN) match the host name, to prevent me (I have a cert for ssl.example.com) from interposing myself between a client and your server (www.some_domain.com) with my valid CA-signed ssl.example.com certificate.
Now if you use a client that does not support certificate verification, then yes, you are vulnerable to a MITM. For example when you use SSH and connect to a host for the first time and do not already have a copy of the host key stored on your machine (perhaps you got it on a floppy, loaded it from a web page, or some other method of getting it that you trust) then you must blindly say "Yes, I trust this fingerprint is correct." If you do this, then you may have been MITM'd, and you wouldn't know.
The best bet in this case is to check the actual server certificate once you log in and make sure that it matches the one you just accepted. You'd need to "cd /etc/ssh; cat ssh_host*.pub" and compare the output of the server keys to the one just entered into your ~/.ssh/known_hosts file. True, if you were MITM'd, then the cracker could be re-writing the keys you read from your cat command, but that's a pretty high bar for it to get over. (You might run 'less' or 'more', etc, so it's difficult for it to know when you're viewing the actual server key.)
So, in summation, if your use of SSL (or any public-key crypto) doesn't include certificate verification (or the appropriate analog), you are always vulnerable to a MITM attack. Major HTTPS implementations do not fall into this category.
When a machine joins the network and gets an IP address and attempts to hit a website, it will attempt to go through your firewall. You'll want to have this machine redirect the connection to a webserver on that machine that shows a "authenticate in some way, shape or form." Using whatever logic you want, it decides to allow this machine to go out the firewall unstopped. You could probably have this program write the IP address to a file or database or something.
Some other process picks up that there's a new machine that should be granted access, and it creates a new iptables rule to allow it unrestricted outbound access, thus bypassing the "redirect everyone to our 'authenticate' page".
Now the next issue is how to keep a new person from using this same IP address. You could watch for MAC address changes and remove the iptables rules if the MAC changes.
This is a bit hasty response - heading out the door.
After having this thing for a month, the things that are not as happy are:
The last one was a particular problem for me. One of the most pressing reasons to get this was to have ssh (using TopGun SSH) access from my phone in case of emergency, or just feeling the need to check my email with Mutt. If you closed the phone to pick up your daughter, your connection was dropped because you launched the phone when you opened it. I used Buttons-T to get around this by telling it to do nothing when the phone is opened, and no problems since then.
The unit is probably heavy if you're used to a sleek model (I wasn't) but I have no problems keeping it in my pocket around the house at night.
One aside: I've tried getting the TopGun SSH source, and can't seem to get the Login portions that it requires. Anyone know where I can get the complete source? Emailing the author(s) hasn't worked. I'd like to do a code audit to make sure it is correctly verifing host keys, which I suspect is is not.
The second type they have is the "PCS Short Mail Message". This is the one that claims compatibility with non-sprint customers, and is presumably the SMS message. I've probably had 20% of these dropped as I was testing. Now the real problem is that on my phone (Treo 300) you cannot read these messages, you need to click on the URL which sends you to the sprintpcs page, from which you must log in and read the message. This is annoying enough as it is, but the real problem is the fact that the sprintpcs page, for whatever reason, doesn't render on the phone itself. Sure, it works in Mozilla, but the point is to have them at your fingertips, not your desktop.
Sprint has a free web page where you can send the "One Way Messages" so it doesn't cost a thing. It doesn't even require cookies or anything, so you could even automate it with a brain dead shell script.
I wanted to have a simple indication when I get new emails when I'm out and about, so I set up a procmail rule that pipes a copy of certain emails to a program email2pager. This program determines if it should send a message (time of day, if I'm active on the mail server, etc) and then scans the email for the Subject and From, then goes and grabs the first bit of the message (stripping MIME headers, "So and so said", commented text, remember, 160 characters max) and then sends it to a second perl script (misnamed sms-sprint) which uses LWP to connect to the Sprint page and send the message.
It works without sending the whole message to Sprint. Anything that is sensitive should have been sent with PGP, of course.
If anyone is interested in the scripts, let me know.