Slashdot Mirror

You can use VoIP with IPSec to secure your phone calls, as long as both sides have the right software installed. The IPSec encryption algorithms are up to you, so if you want to use Elliptic curve cryptography (as donated to OpenSSl by Sun), you can.

The license of OpenSSL is a conjunction of two licenses, One of them being the license of SSLeay. You must follow both. The combination results in a copyleft free software license that is incompatible with the GNU GPL. It also has an advertising clause like the original BSD license and the Apache license.

Is it prohibited again? Silly. You can get OpenSSL all over the world. What's the point?

• OpenSSL - support program
• OpenSSH - connections in and out
• Mutt - email
• nmap - scanning tool
• libpcap - support library
• Ethereal - network sniffer
• mtr (Matt's TraceRoute) - trace problems
• whois (ARIN compatible) - find where the problems are
• tf (tinyfugue) - BBS client
• mangband - multiplayer ascii game

0.9.6d is the latest. Where did you get e?

Fortunately, the open-source SSL systems also provide a solution to this problem.

Look here

Tells you how to install your self-signed certificate into your clients browsers.

For anyone with too many clients to do this practically... well if you have that many clients you should be making enough money to buy a certificate from a trusted authority.

I know this is a trivial thing, but it's a real pain in the butt to have to use ksh all the time because most Solaris boxen I've worked on don't have Bash installed by default.

The same goes for OpenSSL and a bunch of other tools that would be great to have but that I cannot count on being there.

On the other front, having Gnome as a gui readily available is definitely deserving of kudos. If only I had more than ssh access to most of the boxes I work with, I could actually use it. We have Hummingbird Exceed, but it's such a HUGE pain to set up. Neither myself, a reasonably good programmer, nor any of the sysadmins at the very large bank where I work know how to set it up.

Alas.

-- Kevin J. Rice

Apache and xinetd are hardly if ever linked to. They're not even libraries. Every GPLed program that wilfully uses OpenSSL must add a special exception that they may link the program with OpenSSL. Had the licensing for XFree86 always been this way, just as OpenSSL's has, we wouldn't have this problem. Actually, it's not the GPL-incompatibility of the license that is the problem, but the fact that we have a very abrupt change from being GPL-compatible on the one hand to suddenly becoming GPL-incompatible. This change affects thousands of GPLed projects that depend on the XFree86 libraries, and would require that each and every one of them have a similar special exception as GPL programs linking to OpenSSL do.

Sorry, typo. This should have been OpenSSL.

Free implementation?

See OpenSSL and Sun's announcement for including ECC code in OpenSSL.

If you're using IP-to-IP VoIP instead, the FBI will just use Carnivore.

VoIP traffic will have to be end-to-end encrypted. There are many ciphers to choose from (OpenSSL being one possible library).

But, VoIP traffic may have some very predictable pattern in it, which could subject it to cryptanalysis. Even when session keys get renegotiated every now and then, I wouldn't completely rely on this.

People who are interested in keeping things secret, will have to avoid (encrypted) VoIP completely, and revert back to plain old text. If they are really paranoid, they could even use one-time pads, like, say, pairs of CDRs or DVDs full of truly random bits. Such a one-time pad would also last much longer without VoIP!

If you're using crypto, the FBI will just break into your house/office and backdoor your computer.

Exactly! Crypto is just one possible technical measure to make it harder for the feds to eavesdrop things on a wide scale. If you're on their radar, you have much bigger problems than encryption alone.

And don't forget traffic analysis! Even with securely encrypted channels, the feds will still know that A is communicating with B. They'll also know when they are communicating, how often and how much they exchange. Correlating this with other informations can help their investigations.

Have YOU already patched your OpenSSH and OpenSSL packages and sealed the latest holes ?

If not, do it now, PLUIIISE ;-)

I don't see anything about OpenSSL in that link, only OpenSSH. The OpenSSL vulnerability was reported several days after that post.

Speaking of OpenSSH, it's possible that the OpenSSL vulnerability may render OpenSSH vulnerable. Apparently, the newer versions of OpenSSH do not use OpenSSL for signature validation; however, Apple uses a somewhat older version of OpenSSH (3.4p1).

One.

Sure, it compares favorably with openssh, but it does not even come close to my standard of not having "any weekness [sic]".

The only available free-software SSL telnet implementations all use openssl, or its predecessor SSLeay (please correct me if I'm wrong; I would love to learn about other options). This SSL library has had numerous security updates in the past. I would hardly call this record unbeatable.

I use telnet over freeswan IPsec, and I like this combination very much, but no matter what you do, you have to be on your toes.

Thanks for the warning. I'll install right now since that sounds completely secure and stable. And I'm sure lsh doesn't come with its own set of problems to be exploited in the future.

OpenSSH has been very good to me, so I'm just going to patch it all up to 3.7pl1 and move on, just like I do with MS stuff and any other software made by us slightly evolved apes. I don't need to go and load some buggier crap on my network and learn how to apply bandaids over a new system just because it is the spotlighted darling of the moment for GNU.

Don't forget that compiling your own OpenSSH ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable /openssh-3.7p1.tar.gz needs the updated OpenSSL http://www.openssl.org/source/openssl-0.9.7b.tar.g z

Two security companies and a publisher (and a regular joe). I'll bet if Foundstone and eEye turned *alot* of their resources on the linux os/apps or Sun os/apps, we'd see alot more reports. The reports wouldn't be nearly as visible since Microsoft actually bothers to go out of their way to annouce them.

Sure. I used the CA.pl script to do it. The man page is located at http://www.openssl.org/docs/apps/CA.pl.html. Here are the commands I used (make sure to have the openssl binary in your path):

/usr/local/ssl/misc/CA.pl -newca
/usr/local/ssl/misc/CA.pl -newreq
/usr/local/ssl/misc/CA.pl -signreq
/usr/local/ssl/misc/CA.pl -pkcs12

Just follow the prompts and it should generate a .p12 certificate, which you can then import into AIM.

Hope this helps.

Yippee! Yahoo! He picked my question and answered it! (does happy joy dance)

Now that that's over with... I think his answer makes projects like OpenSSL more important. We can all look over the implementations, they're thrashed by the community at large, and they've proven to be quite responsive when someone does find a vulnerability.

Now, off to my next assignment - writing an access rights repository using the M$ Foundation Classes Crypto API. *sigh*

Hmm, interesting... my guess is that's just some overzealous copy and paste from the previous security update.

Now, as for which OpenSSL bug this is for... my /usr/lib/libssl.* and /usr/lib/libcrypto.* are still dated 03/03. Here's a list of the files included in the update:

./usr/bin/make_printerdef Tue Mar 18 18:40:38 2003
./usr/bin/make_smbcodepage Tue Mar 18 18:40:40 2003
./usr/bin/make_unicodemap Tue Mar 18 18:40:42 2003
./usr/bin/nmblookup Tue Mar 18 18:40:43 2003
./usr/bin/rpcclient Tue Mar 18 18:40:41 2003
./usr/bin/smbcacls Tue Mar 18 18:40:43 2003
./usr/bin/smbclient Tue Mar 18 18:40:35 2003
./usr/bin/smbcontrol Tue Mar 18 18:40:38 2003
./usr/bin/smbpasswd Tue Mar 18 18:40:39 2003
./usr/bin/smbspool Tue Mar 18 18:40:36 2003
./usr/bin/smbstatus Tue Mar 18 18:40:37 2003
./usr/bin/testparm Tue Mar 18 18:40:36 2003
./usr/bin/testprns Tue Mar 18 18:40:37 2003
./usr/libexec/httpd/libssl.so Tue Mar 18 11:33:25 2003
./usr/sbin/nmbd Tue Mar 18 18:40:34 2003
./usr/sbin/smbd Tue Mar 18 18:40:33 2003
./usr/sbin/swat Tue Mar 18 18:40:35 2003

So it looks like OpenSSL itself wasn't updated--only mod_ssl for Apache. It's now at version 2.8.13, with fixes for the RSA timing attack. Seems like they should've instead upgraded OpenSSL itself to the version that always turns on RSA blinding.

Is the U.S. Department of Homeland Security also going to try and take care of software developed internationally?

For example, it seems that a lot of OpenSSH development is done in Canada and Germany. And the server is run out of Canada.

The OpenSSL team looks primarily international too (UK, Germany, Sweden, New Zealand). There server is managed by Brits and Swedes.

Actually... I think you'll find that a lot of crypto software is based outside the US. Probably due to constraints placed on crypto development in the last decade.

The fix is pretty trivial, the second error check is done even if the first fails, thus removing any time based information (i.e. data takes about the same time to traverse both checks whether it fails the first or second one), thus denying the attacker the needed information. Fixed versions of OpenSSL have already been released. For more information please see OpenSSL Security Advisory [19 February 2003].

As a further note the BBC article is wrong, the quote "It is the first time we have noticed a security problem in the SSL protocol itself and not in how we use it or how we implement it" is either a misquote or flaw. If the flaw were in the protocol itself the solution would not consist of a 30 line patch to OpenSSL's error checks.

In the case of openssl [9], a new version has already been released (0.9.7a) with a countermeasure against our attack.

Released yesterday: http://www.openssl.org

With a Do Not Call list, one single entry covers all my phone extensions. Since the teleslimers will be comparing only the basic phone number, and not the number with its extension, against the list, by simply having my number without any extension in the list, a proper lookup will match and they can skip that number. None of my extensions will be called.

The issue is how to do this for email addresses. Many mail servers allow for "extensions" by having a certain special character such as "-" or "+" or "." followed by an "extension". By simply having the email account of the part before the separator, you automatically have every possible extension. Some people call this tagged email. And example would be jsmith-foobar@example.net where only jsmith@example.net would be in the list.

Many people even have their own vanity domain names, and regardless of what username is used before the @-sign character, they get the mail like the whole username were the extension.

For a registry to work, for at least those who are required to use it, it must meet at least these two requirements:

• Supports all user email addresses, including extensions
• Easy for the bulk mailers to compare their lists against
• The raw list itself must not be distributed

I looked at the registry run by the Washington Association of Internet Service Providers and found that the verification process only works one at a time. This makes their registry virtually useless. Of course, distributing the addresses in the raw will be worse, as it will get in the hands of spammers out of the country, and everyone will just get more spam because now spammers will have a list of address that are even more likely to have someone reading. And some will be mass mailing to such a list just to destroy the effectiveness of registering.

One option is to distribute an SHA1 checksum of each address. Then all that needs to be done on the mailer's end is to test each address by generating the checksum and looking that up in the database.

But even that has a risk, and I'm wondering if even that should be allowed. That risk is that spammers will run all their millions of email addresses through the process, and produce a subset of those who are registered, and then from out of the country ... they will spam the hell out of just those.

In the end I think the only real solution is for a law that establishes two distinct networks (same address assignment base, but disjoint routing), one where spamming is allowed, and one where it is entirely prohibited under threat of jail time (for the executives in the case of corporations, LLCs, etc). Each ISP can then choose to service one or the other or set up dual but separate facilities to serve both. Wanna bet which network most will choose?

http://registry.waisp.org/

Pros:

• It appears to be free to register
• Does not appear to be distributing the list

Cons:

• Too hard to register lots of addresses
• Cannot register just a general domain
• Verification is only one at a time and way too hard to do

My conclusion is this site is a joke. Do they expect to handle millions of lookups an hour?

What they should do is distribute a list of the 160-bit SHA1 checksums of the registered addresses. Then it's simply a matter of the spammer hashing each email in their mailing list and looking that up against the list. If there's a match, bingo.

Keep your data out of the databases. Use cash, ask marketers to remove your name from their lists. Use cash. Use cash. Use cash.

If you've got a "shoppers club" card with your name attached to it. Give it up. Cut it up. Get another one - without your real name and address.

Encrypt your IM traffic with others that are capable. Put SSL on your web server.

Adopt IPv6. Setup IPsec on IPv4/v6 connections. Use SSH (duh!). Get an anonymizer.com account. $30 bones for a year. You can get a 6-month free trial if you sign up as a member of the EFF. $25 bones. You get a sticker. Spend a little more and you get a hat or a T-shirt. Do it.

If you've got flash, watch this.

No need to contribute "useful" data to the databases, right?

You can also do the same thing with OpenSSL

comes with openssl. It even has a nice perl script to make it easy.
What Verisign and co have that you don't is their root certificates installed with the browsers by default. For internal use you should have no problem using your own certificates. For external use, where an existing business relationship exists (ie you aren't selling to the public, but to people who can trust your cert because they know who you are) it should take little more than a quick explanation.

Open SSL Security Advisory from July

When I first heard about this "virus", I must admit my sphincter clenched up a bit, being responsible for more than a few Open SSL ecommerce servers (and just having started a week off from work to boot). But after a looking into it for about 10 seconds, I realized I was ok since I upgraded in July.

Am I missing something here or are the people that did get affected by this people who simply ignored the July warning?

OpenSSL is written by the OpenBSD people

Not quite.

OpenSSL is maintained by OpenSSL core members: Ralf S. Engelschall, Ben Laurie, Mark J. Cox, Dr. Stephen Henson, and others developers.

OpenSSH was written by OpenBSD members (Theo de Raadt, Niels Provos, Markus Friedl, Dug Song, and others). OpenSSH uses OpenSSL as a cryptographic library source (it is highly optimized for many processors).

>So, that means Linux sucks too, right?

No, Linus didn't make Apache or the OpenSSL library (the real problem).

If anyone deserves the blame for this, its the OpenSSL team themselves (and I would hedge a bet more of them work for BSD rather than Linux, just by the license). They caused the vulnerability. One would think that a team of programmers who are trying to create a set of high-security tools wouldn't _ever_ have a buffer overflow. That's the kind of mistake a green programmer like myself would make.

The fact is people blame Microsoft for Nimda because Microsoft made the vulnerable IIS webserver. Blame went where blame was due.

So, anyways, blame the right people. Microsoft for IIS, OpenSSL team for OpenSSL.

How many webserver administrators have the skills to look at the Apache sourcecode (or in this case, the OpenSSL sourcecode), find the bug, and fix it?

All the skill it should take is to apt-get upgrade or up2date, or whatever the distro in question uses for updates. Debian woody had the patch posted immediately. So the skills needed to update your Apache system are no different from those needed to patch code red (Which, a year after its creation, is still roaming around)

The often tauted ability to "go in and fix things" or even to simply "contribute" is highly overrated. Who found and fixed this bug? Was it some random user, or one of the original developers?

Well, judging by the advisory from the OpenSSL team (Dated July 30, btw, this is hardly a new issue) and a cursory glance over the developer list, the advisory issue was not found by anyone on the development team. So, I'm going to have to go ahead and disagree with you. I consider the ability of users to find and patch security vulnerabilities to be a benefit of free software that simply cannot be overstated.

Having said that, I'll concede the obvious. Most end users are not skilled in the ways of finding or fixing bugs. However, there are zero end users of proprietary tools who even have the option of patching security holes in the software upon which they depend.

So, while some may say "But any user can find/fix security holes when it's free software!" I'll simply say "But any user has the freedom to find/fix security holes when it's free software!" Whether or not the user has the skills is irrelevant, what's important is that the option is there.

How many webserver administrators have the skills to look at the Apache sourcecode (or in this case, the OpenSSL sourcecode), find the bug, and fix it?

All the skill it should take is to apt-get upgrade or up2date, or whatever the distro in question uses for updates. Debian woody had the patch posted immediately. So the skills needed to update your Apache system are no different from those needed to patch code red (Which, a year after its creation, is still roaming around)

The often tauted ability to "go in and fix things" or even to simply "contribute" is highly overrated. Who found and fixed this bug? Was it some random user, or one of the original developers?

Well, judging by the advisory from the OpenSSL team (Dated July 30, btw, this is hardly a new issue) and a cursory glance over the developer list, the advisory issue was not found by anyone on the development team. So, I'm going to have to go ahead and disagree with you. I consider the ability of users to find and patch security vulnerabilities to be a benefit of free software that simply cannot be overstated.

Having said that, I'll concede the obvious. Most end users are not skilled in the ways of finding or fixing bugs. However, there are zero end users of proprietary tools who even have the option of patching security holes in the software upon which they depend.

So, while some may say "But any user can find/fix security holes when it's free software!" I'll simply say "But any user has the freedom to find/fix security holes when it's free software!" Whether or not the user has the skills is irrelevant, what's important is that the option is there.

I think you are in over your head, and you should go read as much as you can about cryptography before you even start. Your question indicates to me that you have a long way to go, although I m admittedly making a few assumptions, based on your post.

First, inventing your own algorithm for cryptography is generally not a good idea (except for learning purposes). There are proven algorithms on the market, and widely available libraries to perform the crypto. Various algorithms have different uses - for example, some are very strong but slow. Others are quick but weaker. Some employ public keys, others have some sort of key exchange. Some are good for streams, others require the entire data packet prior to producing any results.

Many common implementations (like SSL, PGP) use a combination of crypto algorithms (RSA, blowfish, DES3, many others) to optimize their results for their purpose. For example, it's common to use RSA (slow, strong, but only for a small amount of data) to establish a key pair and use another algorithm that is faster, but using the keys exchanged previously.

Public disclosure of your algorithm is the only way to insure appropriate peer examination and find the flaws. Writing your own algorithm is unlikely to provide that sort of peer review. And commercial viability depends on this sort of peer review (unless you are M$, writing the Excel protection routines...)

Go read all you can before you start! It's a very interesting topic! Best of luck.

I'm not convinced that that even small-time criminals will be forced to downgrade. I can pick up source code for twofish at the local library or on the web and just about any library capable of DES can produce 3DES. As such the cost of developing a strong encryption program is trivial. A quick google search found an example of how to use OpenSSL to produce DES-encrypted code. I find it doubtful that DES will disappear in the new future, because it appears to be the lowest denominator for regulation.

Which points to the fundamental futility of regulating cryptographic code. Source code for AES, Blowfish, Twofish, and DES has been published widely as part of public review processes. Developing a new cipher is tough but using an existing cipher is relatively easy. Weak ciphers such as DES can be made stronger by using multiple rounds of encryption. The materials required for producing a cryptographic program are free.

However, x.509 is more suited to compannies, as each public key must be signed by a trusted certificate authority to be valid. (e.g. Signed by Thwate.... otherwise use openSSL and set yourself up as a certificate authority and generate your own x.509 certs). This is only really practacle for a large company.

Individuals are better suited to PGP because of its "web of trust" model eliminates the need for certificate authoritys, but will be impractacle for a large organisation. (Its no wonder NA failed to sell PGP to companies.... the existing x.509 standard is mutch more suited)

See this link

Visit here or man openssl for more information on creating and managing certificates.

ssh
gpg
https://
webdavs://
imaps://
...

Big Brother can watch all they want, but they'll only see my random bits.

• 7 go to the internet looking. (3 go to a commercial source)
• Of those 7...
  • 2 find what they need the first time. Their money is *poof* gone. They've made the move. They'll do this again.
  • 2 find what they need, but it doesn't work quite right. They want free so badly, they'll screw with it till it works.
  • 1 finds something close, but it doesn't quite work. This one hires a consultant to tell them how to do it... they'd rather pay a human than buy software.
  • 2 don't find it, and buy software.

Let's just say that Ralf is the commited guy for standard packages.

http://www.openssl.org/
http://www.modssl.org/

To say a few.
He's the guy that wrote mod_rewrite back in the old days. Tough guy.

One of the tactics of the black hats seems to be to dig around for information from places, and perhaps in ways, which might not be quite so easy for them to get access to, when the white hats learn to use encryption as well as "they" do.

For example, consider mining an airline booking site to see which flights have special prices. This type of information retrieval might become better protected, because such information could lead to speculation about the human-density on the flight.

Consider also, that Europe, as Us, is devastated by every new MS worm that comes around. But if they'd only use SSL server encryption more widely, they'd be unbothered by such simple virusen. Managers will buy more servers, because SSL takes more horsies, (as every other form of encryption), users will share information in a more sensible way, the economy will rebound, etc., etc.. :)

I contend that the most interesting authorities built out of X.509, in any case objCA, sslCA, and objsign (from openssl docs and Netscape definitions), should continue to be widely encouraged. emailCA, perhaps is for the more mature organization, but an organizations email can sometimes be the biggest "hole" of all. It should be closed-up, in any good business activity, anywhere, eventually.

The point is, everyones already got this stuff. The playing field is even, and we have to fight dishonesty with the same tools as are being used to hide it.

Not to worry unless someone tells you to put your certificate on your head or your hand (right). Right?

With Jon Katz it always have to do with Your Rights Online [tm], doesn't it? If you're concerned about your online communications being monitored, use encryption, like

• SSL
• PGP
• ssh

And if you're concerned that the government can break those, start supporting research for stronger encryption.

I think every packet that goes into the Internet should be monitored, and I know it can. If there's something I want private, I'll keep it private myself, and I expect everybody to do the same. Expecting the law to protect you when you use insecure technology is somewhat like those who expect the law to protect them when they use insecure encryption on DVDs. Pick up the slack yourself and quit asking the government to do it.

From the ipsec manpage in FreeBSD:

DESCRIPTION
ipsec is a security protocol in Internet Protocol layer. ipsec is defined for both IPv4 and IPv6 (inet(4) and inet6(4)). ipsec consists of two sub-protocols, namely ESP (encapsulated security payload) and AH (authentication header). ESP protects IP payload from wire-tapping by encrypting it by secret key cryptography algorithms. AH guarantees in-tegrity of IP packet and protects it from intermediate alteration or im-personation, by attaching cryptographic checksum computed by one-way hash functions. ipsec has two operation modes: transport mode and tunnel mode. Transport mode is for protecting peer-to-peer commuication between end nodes. Tunnel mode includes IP-in-IP encapsulation operation and is designed for security gateways, like VPN configurations.

So, yes. IPSec will secure things. But you still have to look at the amount of users who have trouble finding the website they want, let alone setting up IPSec. Even still, for every remote IP address you wish to have security when downloading from, they have to configure IPSec at their end. So, that means you wouldn't just have to secure your connection to opennap servers, but also users on the opennap servers you want to download from. But I'm sure, there are also many other examples of how IPSec could be effective, but would also be a pain to configure for large amounts of IP address, some of which dynamic. Maybe what were looking at is the rewriting of some protocols to support secured connections & transfers, as this would be an easier task of just installing a secured client/server, instead of having to setup IPSec. Though, IPSec is good in cases where you have a remote system that you want all communications to be secured.

I might do a little work on securing lopster & opennap with OpenSSL to support secured logins & transfers, when I could be bothered. It could be interesting. I'm sure an implementation of this would take time for people to start using, though.

OpenSSL is a library, not a set of programs like OpenSSH is. OpenSSH uses the OpenSSL library to do the encryption. You can find API documentation for OpenSSL here.

Am I the only one thinking that SOMEBODY -- be it the PGP people, the Free Software Foundation, or Microsoft for that matter -- should figure out a TRULY easy, TRULY fast, TRULY seamless means for the common email user to encrypt a message?

Yup, it's been done. The standard is SMIME v3 amd it uses digital certificates for encryption and authentication. Microsoft's IE (4 and up) has support for certs, so does Netscape 4.x (not sure about NS v6 tho'; the "final preview" I looked at last year had all the crypto removed). To encrypt an email is a click of the menu bar button. Ditto to sign an email. When you receive a signed/encrypted email, Outlook (or Outlook Express, or Netscape Messenger) displays an icon to denote the fact. Couldn't be simpler. Why isn't it more widely used? Well, you need to have a certificate. You can pay for one from Verisign (probly not a popular choice for /.ers). You can get a free one for email only (certs can be used for other types of authenticaton, eg web site access) from Thawte, but they require all sorts of personal info from you, including SSN, IIRC (probly even less popular choice for /.ers). However, if you're willing to add a new root certificate to your browser (which is easy) you can make and use your own certificates. I use certs for email security and also for securing acces to certain web-based admin pages. Secure and convenient. Luvvly.

If you're interested in using certs, you can do most everything you need with OpenSSL.

Of course, your certificate wasn't signed by a known CA, but getting a certificate signed by a CA only says "this certificate really belongs to this person", it doesn't say "this person is trustworthy" or "this person knows how to code a website that can't be hacked." And really, the latter two are much more important. Most users don't get this, so for an e-commerce website, getting an official cert is a good idea. Heck, for ecommerce, $150 for a cert is a relatively small business expense. But for your own use, you may as well just stick with self-signed certs.

- Morty

This was submitted almost 3 weeks ago, anyways, its nice to see that people are still interested in the BSD's.

Recently I optioned on either buying two more Nokia 650 firewalls for my network and installed three new OpenBSD boxes using a combination of Trex, and IPF. While Checkpoint is a pretty cool firewall, I figured we (my company) didn't need to go out and spend more loot on firewalls. Sure IPF and Trex don't have true stateful inspections, and sure you can't do as much as you can with Checkpoint, but here are some of the neat things I managed to fiddle with. (posting this for this who do the fw things ya know)

On my Checkpoint FW I'm allowed the ability to mainpulate time based rules. (meaning I can allow in, out, block, on certain times of the day etc.) Being that at night (in case things go bonkers) servers go down, I made a simple shell script that is cron'd to open a connection at 8pm daily (when I'm home away from work) to my home subnet. This is pretty similar to Checkpoint's time based rules.

Not a major hack but it does me justice

Using a combination of FreeBSD, NetBSD, and OpenBSD at work (I'm senior admin so I get to use whatever I want) I also took the liberty of stunneling just about everything I could with OpenSSL so even if someone got unto out network, traffic is pretty secure for the most part.

Anyone else care to share some tweaks, tips and stuff on this boring Sunday?

These days, OpenSSL is widely distributed (included in Red Hat 7, for example) and runs on lots of platforms; and SSL is simply a more mature protocol than SSH. SSL supports certificate based authentication at both the client and the server ends--as normally used, it's much less vulnerable to MITM attacks than SSH; there's a big CA infrastructure including commercial CA's that check real-world credentials, so you can be reasonably sure the host you're connecting to is what it says it is; there are also plenty of hardware SSL authentication devices (e.g. smart cards containing X509 cert/key pairs) so you don't have to worry about your keys getting accidentally copied, etc. etc.

Maybe there's a good reason that SSH usage is increasing rather than decreasing, but I haven't figured it out. Any thoughts?

While RMS would have preferred that we open sourced the whole application, the fact that we have released independently-usable programs as a result of our work is enough to satisfy the GPL and stave off a little of the grumbling. That is also why RMS says it's okay to call GPL'ed CORBA components from proprietary programs -- every little piece that's GPL'ed helps further his goal of being able to do everything with free software. The requirement is that the GPL'ed component be a complete, independently usable program or component -- this gives RMS something that he can personally run as part of his totally-free system. Just releasing a few unusable fragments of code (or a CORBA component that requires proprietary components in order to be useful) won't do the job.

Regarding network protocols, I wouldn't use 'ssh' or 'openssh' anyhow. Investigate 'openssl', and write your own protocol based upon it. I could not use OpenSSL for the closed source project that I worked on because of the RSA patent (which is now expired so it's not a problem for you, back then it WAS a problem) so I wrote my own Diffie-Hellman based protocol, but nobody should have to go through that hassle nowdays.

-E

AFAIK, IANAL and all that.

You'll be wanting to read the OpenSSL licence then?

But it seems fine to me. OpenSSL is released under a variant of the BSD licence (enforced credit-where-it's-due), which is more or less carte blanche to do what you like provided you put some thank you's in the appropriate pages. Apart from that, fine, tunnel what you like. Try hacking around with stunnel first (/usr/ports/security/stunnel/).

Dave