8 Replies Latest reply: Jun 8, 2008 9:11 PM by rkovelman
Peter Glock Level 1 (45 points)
I want to improve the security of information being sent over our network, both internally and for internet connected users. For internet connected users I can set up VPN access reasonably easily but I am looking for a way to make a secure connection transparent for both external and internal users.

I have set up LDAP look-ups for shared address book to use authenticated SSL (and opened the relevant port on my firewall) so that it is now irrelevant to a user whether they are inside or outside the firewall when using the address book.

Under Tiger there is an option to encrypt AFP (using OpenSSL I believe) for both login and for file sharing. Under Leopard it seems that there is only encryption for login but not for file transfer so that anyone sniffing the local network can capture any file (I've tried this successfully using ettercap).

Is there any way to replicate the Tiger behaviour under Leopard?

Power Mac g5, MacBook Pro, 2 x iMac g5, g4 Quicksilver, mac minis, iBook G4..., Mac OS X (10.5.2), Infrant readyNAS 600 (2TB)
  • Peter Glock Level 1 (45 points)
  • rkovelman Level 2 (320 points)
    I would make sure under authentication you select Kerberos, kill users after they have been idle, make sure you have a valid cert, disable guest access.

    For SSL go here:

    Below is what that link states

    The Change

    The difference between 10.4 and 10.5 lies entirely in /etc/openldap/ldap.conf. Where before it used to say

    TLS_REQCERT = never
    now it says

    TLS_REQCERT = demand
    This change means that the underlying ldap client will only use SSL certificates that it thinks are valid dropping the connection attempt if it thinks the cert is bad. So, what constiutes a valid cert?

    Out of the box... nothing. The LDAP client trusts no one. Even if you actually paid for your SSL certificate and you have no issues when you use it to secure a website, the LDAP client will still refuse it. Annoyingly the GUI, in this case Directory Utility, will happily show you a green dot next to your server, it's just that it won't actually be used. If you require binding and SSL, that should fail as well.

    While this is annoying if you didn't expect it, I find it hard to argue that it was a bad move. Without validating a site against its own certificate left the client systems open to something as simple as a DNS poisoning attack. So I do feel that this is a good thing, but it cetainly does take a bit more work to get things functioning.

    Test via the CLI

    The easiest way to test what exactly is going on is to use the ldapsearch command to verify if you're able to connect or not. This assumes that you've first set up OD and enabled SSL for LDAP, either using the default certificate on the server or one you've configured yourself.
    ldapsearch -v -x -H ldaps://biggie.afp548.com -b "dc=biggie,dc=afp548,dc=com"
    Substituting in your correct server FQDN and search domain. This should fail on a stock 10.5 install with this error.
    ldap_bind: Can't contact LDAP server (-1)
    additional info: error:14090086:SSL routines:SSL3GET_SERVERCERTIFICATE:certificate verify failed
    Fairly self-explanatory, at least to what the error is. So now how to fix it.

    Get the Cert

    You're going to need to feed the cert to the LDAP client so that it knows to trust it. While it's possible to do this via exporting the cert from the server itself it's typically easier to use the "openssl s_client" to snarf the cert.
    openssl s_client -connect biggie.afp548.com:636
    Which should come back with a deluge of information for you. Within that is going to be a dozen or more lines that are blocked off by:
    -----END CERTIFICATE-----
    Take that text, including the begin certificate and end certificate lines and paste them into a text file. A CLI text editor would be best for this to ensure that you don't accidentally save it as a .rtf or something funky like that.

    For purposes of demonstration we'll assume that you've saved the cert to /tmp/ssl.cert.

    Note: you should get an error number 18 or 19 when using the s_client. This refers to either a self-signed certificate, 18, or a self-signed certificate in the chain, 19. Keep this in mind as the next step should clear this out.

    BTW, control-c to get out of the s_client connection.

    Test the Cert

    Now that you have the cert sequestered into a text file you can test again with s_client manually specifying the certificate.
    openssl s_client -connect biggie.afp548.com:636 -CAfile /tmp/ssl.cert
    Which should display similar output to before, however, with a significant change to the last line:
    Verify return code: 0 (ok)
    Instead of either the 18 or 19 that you were getting before. This means that you've successfully managed to get openssl to be happy with the certificate that you're using on the remote server. So now to make LDAP as happy...

    Edit ldap.conf

    You are going to need to add a new line to /etc/openldap/ldap.conf that points to the certificate you've just pulled down. I tend to keep things tidy here and create a /etc/openldap/certs folder and then just copy the text file that we got before into there. Here we'll assume you renamed the file the name of the server and put it into this location.

    After moving the cert you can add one line into /etc/openldap/ldap.conf
    TLS_CACERT /etc/openldap/certs/biggie.afp548.com
    Now retest with the ldapsearch command and see if it works.
    ldapsearch -v -x -H ldaps://biggie.afp548.com -b "dc=biggie,dc=afp548,dc=com"
    Should actually return an LDIF of your whole LDAP setup, so this may take a while. Trim down the search if you want.

    Ensuring OD Works

    At this point you should be able to join and use an SSL-secured OD setup via Directory Utility. So please do that at this time. You may need to kick Directory Services if you had already attempted to setup the LDAP server.
    sudo killall DirectoryService
    Securing a Collection of Certs

    The method above will only allow that one specific server, with that one specific cert to be trusted. If you have multiple LDAP servers you're working with you're going to need to specify those individually, or put them all in the same directory and point ldap.conf towards them. Here's how to do the later.

    Grab all of the certs as before using openssl s_client.
    Now you're going to have to use another OpenSSL utility to get the certs into a hashed format.For each cert you will run the it through c_hash which will give you a name that you'll need to rename the cert file to.
    /System/Library/OpenSSL/misc/c_hash /etc/openldap/certs/biggie.afp548.com
    03be8eb2.0 => /etc/openldap/certs/biggie.afp548.com
    In this example you'd rename your existing cert file to 03be8eb2.0

    Then you can add
    TLS_CACERTDIR /etc/openldap/certs/
    to your /etc/openldap/ldap.conf file.

    Probably best to remove any earlier TLS_CACERT directives you have in ldap.conf at this time as well.
    On the Other Hand

    You could revert the ldap.conf file back to the 10.4 behavior and be done with all this...


    Note that while it would certainly make most of the pain go away, OpenSSL and therefor the LDAP libraries have no concept of what a keychain is. So, no, importing the certs into your keychain won't do anything for the LDAP issue.

    Other Notes

    You will never be able to use the default certificate that comes with OS X Server without changing TLS_REQCERT back to never. The default certificate isn't configured with a hostname so it will never pass an integrity check.

    As mentioned by Mr. McCune in the comments, you may also want to investigate pointing ldap.conf to the default trusted root store that is included with curl on OS X.

    TLS_CACERT /usr/share/curl/curl-ca-bundle.crt
    Which should allow you to use a purchased certificate without having to do additionaly mods to ldap.conf.
  • Peter Glock Level 1 (45 points)
    Thanks for the link I'm also a regular visitor to afp548.com so had come across this article already.

    However, this only provides advice about securing the authentication of afp sessions, not the content of any documents that pass over the wire. If you use wireshark or ettercap you will be able to see that the authentication is encrypted, but data transfer is not.

    So, the question remains - any way of securing afp sessions without vpn or ssh/ssl tunneling?
  • rkovelman Level 2 (320 points)
    Well even a VPN connection is unsecure unless the server is plugged directly in to the VPN Appliance. Otherwise the traffic is still open. The only thing secure is the VPN connection from the mobile user to the VPN appliance. What I would suggest is doing SSL or SSH. Are you trying make certification or compliance? Just curious for why you need such a secure network...
  • Peter Glock Level 1 (45 points)
    I'm following the recommendations of the Jericho Forum (see http://www.opengroup.org/jericho/ ).

    I support a number of mobile users, most of whom are decidedly non-technical. I'm trying to provide all services in a secure way irrespective of whether they are in the office, at home or somewhere else so that they don't have to change behaviour. I've set all email settings to use secure IMAP and LDAP/OD settings to use SSL, now I'd like to do the same for AFP.

    Any help appreciated.
  • davidh Level 4 (1,890 points)
    Well, you might go with an ssl-based VPN such as http://www.sshtools.com/showSslExplorer.do
    or use a dedicated hardware appliance such as the Zyxel SSL10
    http://www.zyxel.co.uk/web/productfamilydetail.php?PC1indexflag=20040908175941&CategoryGroupNo=E16F51B0-706B-4DF0-A596-7 B9250FE96E7

    (SSL VPN functionality also in the higher-end Zywall 70 with IDP
    http://www.zyxel.co.uk/web/productfamilydetail.php?PC1indexflag=20040908175941&CategoryGroupNo=1AD36044-757C-4BCB-83B0-5 510C6E1E708

    I gave the URL for their UK pages (they have US pages as well, possibly others...)
    Or of course, another vendor if you prefer.
  • Peter Glock Level 1 (45 points)
    Thanks for the suggestion. I have been using sslexplorer for several years to give me remote access for admin purposes, I find it very good when tunneling through the various firewalls I find myself behind

    I'm obviously not stating the requirement clearly enough. I want to have a base set of services for mobile users so that they do not have to change anything between working in the office and remotely.

    I have this working for mail, address book and calendars and now want to set up secure access for fileshares and PHDs (for online backup)

    I'm currently using webdav over ssl for giving remote access to shared files, but this causes problems with file permissions (_www is the user for all files created on the server, I would like more granular access), opening/saving files in MS Office and no access to PHDs.

    I could tunnel afp (or maybe smb) over ssh or establish IPSec, PPTP or ssl VPN but this would involve the user understanding that they were 'out of the office' and doing something different.

    AFP over ssh was working in 10.4 server, can I get the same from 10.5?
  • rkovelman Level 2 (320 points)
    I understand what your trying to accomplish but remember that any traffic before the VPN is not encrypted so as of right now your not secure in any way. Going beyond that depending on the VPN connection the data wont be plain text BUT might be easy to grab.

    Have you called Apple and asked about what your trying to do? There is an old Unix way I did it with NetaTalk found here:
    With this you can enable SSL over AFP.