iRODS 4.X SSL configuration between client, resource server and ICAT
783 views
Skip to first unread message
taffel...@gmail.com
Feb 20, 2015, 4:50:03 AM2/20/15
to irod...@googlegroups.com
Hi,
I have a question about the iRODS 4.X SSL network plugin and PAM authentication.
The 'irods_client_server_policy' can bet set to CS_NEG_REFUSE (no SSL), CS_NEG_REQUIRE (only SSL) and CS_DONT_CARE (both are okay). The manual states that "In order for a connection to be made, the client and server have to agree on the type of connection they will share. When both sides choose CS_NEG_DONT_CARE, iRODS shows an affinity for security by connecting via SSL."
This is confusing, because setting the CS_NEG_REQUIRE + authentication scheme to PAM on the client-side is required but on the server-side it doesn't matter if the value is CS_NEG_REFUSE. The client will still initiate an SSL connection, and if the server has the correct environment variables (key, cert, params, etc.) the connection will use SSL. So it seems the server does not use the 'irods_client_server_policy' variable from the irods_environment.json configuration file. Where should this 'irods_client_server_policy' variable be defined on the server-side?
It gets more complicated when there are two servers. For example, let's say we have the following situation:
Laptop client:
- With CS_NEG_REQUIRE (set in irods_environment.json)
- With PAM authentication scheme
- Uses the resource server's cert chain
Resource server:
- Front-end
- With CS_NEG_DONT_CARE (set in irods_environment.json, but does it matter?)
- SSL is setup
- PAM is setup
ICAT server:
- Back-end
- With CS_NEG_DONT_CARE (set in irods_environment.json, but does it matter?)
- No SSL setup
The connection diagram would look like this:
Client <--SSL--> Resource server <--NO SSL--> ICAT
The CS_NEG_DONT_CARE does not work for the ICAT server in this scenario. The resource server tries to require SSL from the ICAT server and fails because it is unavailable. Perhaps I should also setup SSL on the ICAT server, and enable PAM authentication on it?
The manual entries written for SSL and PAM are written with the assumption that there is only a client and a single server, but what configuration should I use on both the resource server and ICAT server to enable PAM authentication from the laptop client? The resource server is a server from the viewpoint of the laptop client BUT it is also a client from the viewpoint of the ICAT server. The manual introduces many environment variables, but I'm kinda at loss whether there is a clear separation between configuration files for the roles of client and server. The 'irods_client_server_policy' doesn't seem to be used by the server in the "client and single server" -scenario.
Basically I want to know how do I tell the resource server how to act like an SSL-enabled server towards the client and how to act as a (SSL-enabled if necessary) client towards the ICAT server. What configuration variables and files should I actually use on the resource and ICAT servers? I've read the manual and I can get it to work with a client and single server scenario, but not with a separate resource server and ICAT server. I will post log error entries if needed, but first I'd just like to hear first about the proper use of environment variables and configuration files.
I'd also be interested in hearing how other people use SSL + PAM with iRODS 4.X resource server + ICAT. As anybody actually tested this?
-- Taneli Riitaoja / CSC
I have a question about the iRODS 4.X SSL network plugin and PAM authentication.
The 'irods_client_server_policy' can bet set to CS_NEG_REFUSE (no SSL), CS_NEG_REQUIRE (only SSL) and CS_DONT_CARE (both are okay). The manual states that "In order for a connection to be made, the client and server have to agree on the type of connection they will share. When both sides choose CS_NEG_DONT_CARE, iRODS shows an affinity for security by connecting via SSL."
This is confusing, because setting the CS_NEG_REQUIRE + authentication scheme to PAM on the client-side is required but on the server-side it doesn't matter if the value is CS_NEG_REFUSE. The client will still initiate an SSL connection, and if the server has the correct environment variables (key, cert, params, etc.) the connection will use SSL. So it seems the server does not use the 'irods_client_server_policy' variable from the irods_environment.json configuration file. Where should this 'irods_client_server_policy' variable be defined on the server-side?
It gets more complicated when there are two servers. For example, let's say we have the following situation:
Laptop client:
- With CS_NEG_REQUIRE (set in irods_environment.json)
- With PAM authentication scheme
- Uses the resource server's cert chain
Resource server:
- Front-end
- With CS_NEG_DONT_CARE (set in irods_environment.json, but does it matter?)
- SSL is setup
- PAM is setup
ICAT server:
- Back-end
- With CS_NEG_DONT_CARE (set in irods_environment.json, but does it matter?)
- No SSL setup
The connection diagram would look like this:
Client <--SSL--> Resource server <--NO SSL--> ICAT
The CS_NEG_DONT_CARE does not work for the ICAT server in this scenario. The resource server tries to require SSL from the ICAT server and fails because it is unavailable. Perhaps I should also setup SSL on the ICAT server, and enable PAM authentication on it?
The manual entries written for SSL and PAM are written with the assumption that there is only a client and a single server, but what configuration should I use on both the resource server and ICAT server to enable PAM authentication from the laptop client? The resource server is a server from the viewpoint of the laptop client BUT it is also a client from the viewpoint of the ICAT server. The manual introduces many environment variables, but I'm kinda at loss whether there is a clear separation between configuration files for the roles of client and server. The 'irods_client_server_policy' doesn't seem to be used by the server in the "client and single server" -scenario.
Basically I want to know how do I tell the resource server how to act like an SSL-enabled server towards the client and how to act as a (SSL-enabled if necessary) client towards the ICAT server. What configuration variables and files should I actually use on the resource and ICAT servers? I've read the manual and I can get it to work with a client and single server scenario, but not with a separate resource server and ICAT server. I will post log error entries if needed, but first I'd just like to hear first about the proper use of environment variables and configuration files.
I'd also be interested in hearing how other people use SSL + PAM with iRODS 4.X resource server + ICAT. As anybody actually tested this?
-- Taneli Riitaoja / CSC
Jason Coposky
Feb 20, 2015, 12:06:17 PM2/20/15
to <irod-chat@googlegroups.com>
the use of PAM enables SSL by for the password exchange explicitly which may be
a point of confusion.
the switches for advanced negotiation are used to enable SSL for all of the iRODS communication over the wire. if you want to use SSL for the full iRODS communication
then we generally recommend that it is either enabled everywhere or disabled everywhere
due to the possibility of information accidentally making it into the clear.
i noted that you referenced irods_environment.json, are you running against a copy
of the master branch?
—
Jason Coposky
Chief Technologist, iRODS Consortium
RENCI at the University of North Carolina at Chapel Hill
irods.org — Take Control of Your Data
--
--
"iRODS: the Integrated Rule-Oriented Data-management System; A community driven, open source, data grid software solution" https://www.irods.org
iROD-Chat: http://groups.google.com/group/iROD-Chat
---
You received this message because you are subscribed to the Google Groups "iRODS-Chat" group.
To unsubscribe from this group and stop receiving emails from it, send an email to irod-chat+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
taffel...@gmail.com
Feb 23, 2015, 7:42:24 AM2/23/15
to irod...@googlegroups.com, jas...@renci.org
Hi,
"i noted that you referenced irods_environment.json, are you running against a copy of the master branch?"
Indeed. This particular copy is from November (4.0.3_cbb69d52b5).
"the use of PAM enables SSL by for the password exchange explicitly which may be a point of confusion."
Yes, I noticed this. But the manual is also a point of confusion.
"the switches for advanced negotiation are used to enable SSL for all of the iRODS communication over the wire. if you want to use SSL for the full iRODS communication
then we generally recommend that it is either enabled everywhere or disabled everywhere due to the possibility of information accidentally making it into the clear."
This is what I thought. This reduces the problem somewhat.
So, here's the problem in a smaller nutshell:
- Resource server has its own SSL key, certificate, etc. I can use something like the following script (simplified) to turn on an SSL-capable iRODS resource server
Config 1 (resource server):
#!/bin/bash
irodsSSLCertificateChainFile=/etc/irods/chain.pem <--- Assume a self-signed cert resource.crt (for testing) and this is renamed to chain.pem
export irodsSSLCertificateChainFile
irodsSSLCertificateKeyFile="/etc/irods/resource.key"
export irodsSSLCertificateKeyFile
irodsSSLDHParamsFile=/etc/irods/dhparams.pem
export irodsSSLDHParamsFile
/var/lib/irods/iRODS/irodsctl restart
- ICAT server has its own SSL key, certificate, etc. Again, I can use the same script and only change the relevant key and certificate variables.
Config 2 (icat server):
#!/bin/bash
irodsSSLCertificateChainFile=/etc/irods/chain.pem <--- Assume a self-signed cert icat.crt (for testing) and this is renamed to chain.pem
export irodsSSLCertificateChainFile
irodsSSLCertificateKeyFile="/etc/irods/icat.key"
export irodsSSLCertificateKeyFile
irodsSSLDHParamsFile=/etc/irods/dhparams.pem
export irodsSSLDHParamsFile
/var/lib/irods/iRODS/irodsctl restart
The questions:
1) Where on the resource server do I define icat.crt (certificate of the ICAT server) as the certificate to use when communicating with the ICAT server? Assume I use irodsctl to start the resource server.
2) Does the resource server require any PAM specific settings/configurations?
Note:
In the above situation, I am able connect as a laptop client directly to the ICAT server with SSL + PAM, but not to the resource server, because I can not get the resource server to communicate with the ICAT server when the resource server uses Config 1 and ICAT server uses Config 2.
Obviously I need some environment variables or configurations on the resource server, but what and where?
So, here's the problem in a smaller nutshell:
- Resource server has its own SSL key, certificate, etc. I can use something like the following script (simplified) to turn on an SSL-capable iRODS resource server
Config 1 (resource server):
#!/bin/bash
irodsSSLCertificateChainFile=/etc/irods/chain.pem <--- Assume a self-signed cert resource.crt (for testing) and this is renamed to chain.pem
export irodsSSLCertificateChainFile
irodsSSLCertificateKeyFile="/etc/irods/resource.key"
export irodsSSLCertificateKeyFile
irodsSSLDHParamsFile=/etc/irods/dhparams.pem
export irodsSSLDHParamsFile
/var/lib/irods/iRODS/irodsctl restart
- ICAT server has its own SSL key, certificate, etc. Again, I can use the same script and only change the relevant key and certificate variables.
Config 2 (icat server):
#!/bin/bash
irodsSSLCertificateChainFile=/etc/irods/chain.pem <--- Assume a self-signed cert icat.crt (for testing) and this is renamed to chain.pem
export irodsSSLCertificateChainFile
irodsSSLCertificateKeyFile="/etc/irods/icat.key"
export irodsSSLCertificateKeyFile
irodsSSLDHParamsFile=/etc/irods/dhparams.pem
export irodsSSLDHParamsFile
/var/lib/irods/iRODS/irodsctl restart
The questions:
1) Where on the resource server do I define icat.crt (certificate of the ICAT server) as the certificate to use when communicating with the ICAT server? Assume I use irodsctl to start the resource server.
2) Does the resource server require any PAM specific settings/configurations?
Note:
In the above situation, I am able connect as a laptop client directly to the ICAT server with SSL + PAM, but not to the resource server, because I can not get the resource server to communicate with the ICAT server when the resource server uses Config 1 and ICAT server uses Config 2.
Obviously I need some environment variables or configurations on the resource server, but what and where?
-- Taneli Riitaoja / CSC
Terrell Russell
Feb 23, 2015, 10:31:18 AM2/23/15
to irod...@googlegroups.com
Hi Taneli,
Since you are using master, you may be better served by staying a bit more current - we're fixing many things very quickly.
The manual may be out of date for the same reason - it will be ready by the time 4.1.0 is shaping up.
The SSL certificates (and keys) need to be the same on all iRODS servers within a Zone. We are not supporting per-route certificates at this time.
The PAM configuration should be consistent as well, as it is only the information about how to connect - the iCAT will handle the actual authentication itself.
I've just made a commit to clarify this a bit in the manual:
Everyone else, please let us know if this type of per-route SSL configuration is something that is compelling. We can capture the use case for our roadmap.
Terrell
taffel...@gmail.com
Mar 4, 2015, 8:48:23 AM3/4/15
to irod...@googlegroups.com
Hi,
"Since you are using master, you may be better served by staying a bit more current - we're fixing many things very quickly."
"Since you are using master, you may be better served by staying a bit more current - we're fixing many things very quickly."
Noted. We continued SSL testing with the newer iRODS 4.0.3_4f0ec88478.
"The SSL certificates (and keys) need to be the same on all iRODS servers within a Zone. We are not supporting per-route certificates at this time."
Okay, this cleared things up a bit.
We managed to get SSL working in our RHEL6 testing environment. It took some time, so I'm writing some of the process here to help future iRODS 4.X SSL pioneers set up their testing environments. Some of the things mentioned in '3)' should really be in the new 4.1.0 manual, as that would help a lot.
1) Creating testing certificates
First things first. For use in our testing environment, we had to act as our own certificate authority to be able to get multi-host self-signed certificates to work with iRODS. Here are all the steps to create working testing certificates for use with iRODS 4.X:
# Generate a private key
$ openssl genrsa -des3 -out testing_env.key 2048
# Generate CSR
$ openssl req -new -x509 -key testing_env.key -out testing_env.csr -days 730
...
(answer the questions what you want to)
...
# Remove password from key
$ cp testing_env.key testing_env.key.orig
$ openssl rsa -in testing_env.key.orig -out testing_env.key
# Create extension file
$ cat testing_env_extension
[ testing_env ]
nsCertType = server
keyUsage = digitalSignature,nonRepudiation,keyEncipherment
extendedKeyUsage = serverAuth
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
subjectAltName = @testing_env_hosts
[ testing_env_hosts ]
DNS.1 = testing_host_1.company.com
DNS.2 = testing_host_2.company.com
DNS.3 = testing_host_3.company.com
# Be a new CA (for testing environments)
$ openssl genrsa -des3 -out testing_CA.key 2048
$ openssl req -new -x509 -key testing_CA.key -out testing_CA.crt -days 730
...
(answer the questions what you want to)
...
# Remove password from key
$ cp testing_CA.key testing_CA.key.orig
$ openssl rsa -in testing_CA.key.orig -out testing_CA.key
# Sign the server certificate request with the CA
$ openssl x509 -req -days 730 -in testing_env.csr -CA testing_CA.crt -CAkey testing_CA.key -CAcreateserial -out server.cer -extfile testing_env_extension -extensions testing_env
# Create chain.pem
$ cat server.cer testing_CA.crt > chain.pem
# Create Diffie-Hellman params
$ openssl dhparam -2 -out dhparams.pem 2048
# Copy the files to their respective locations
See 2) configurations for suggested file locations (note: all the files and file locations are the same across servers).
2) SSL configurations
Lets say testing_host_1.company.com is a laptop client with icommands, testing_host_2.company.com is a resource server, and testing_host_3.company.com is an ICAT server.
testing_host_1.company.com:~/.irods/irods_environment.json
Add the following lines:
...
...
"irods_client_server_policy": "CS_NEG_REQUIRE",
"irods_encryption_key_size": 32,
"irods_encryption_salt_size": 8,
"irods_encryption_num_hash_rounds": 16,
"irods_encryption_algorithm": "AES-256-CBC",
"irods_default_hash_scheme": "SHA256",
"irods_match_hash_policy": "not_strict",
"irods_ssl_ca_certificate_file": "/etc/irods/chain.pem",
"irods_ssl_ca_certificate_path": "/etc/irods/certs",
"irods_ssl_verify_server": "cert",
...
...
Ensure all the files mentioned above exist and are readable by the 'irods' system user. Create the directory "irods_ssl_ca_certificate_path" points to (/etc/irods/certs is suggested). Directory can be empty, but it must exist. Otherwise you will get an error.
Do 'iexit full && iinit'.
testing_host_2.company.com:~/.irods/irods_environment.json AND testing_host_3.company.com:~/.irods/irods_environment.json
Add the following lines:
...
...
"irods_client_server_policy": "CS_NEG_REQUIRE",
"irods_encryption_key_size": 32,
"irods_encryption_salt_size": 8,
"irods_encryption_num_hash_rounds": 16,
"irods_encryption_algorithm": "AES-256-CBC",
"irods_default_hash_scheme": "SHA256",
"irods_match_hash_policy": "not_strict",
"irods_ssl_certificate_chain_file": "/etc/irods/chain.pem",
"irods_ssl_certificate_key_file": "/etc/irods/testing_env.key",
"irods_ssl_dh_params_file": "/etc/irods/dhparams.pem",
"irods_ssl_ca_certificate_file": "/etc/irods/chain.pem",
"irods_ssl_ca_certificate_path": "/etc/irods/certs",
"irods_ssl_verify_server": "cert",
...
...
Ensure all the files mentioned above exist and are readable by the 'irods' system user. Create the directory that "irods_ssl_ca_certificate_path" points to (/etc/irods/certs is suggested). Directory can be empty, but it must exist. Otherwise you will get an error.
Do 'iexit full && iinit'.
3) Some notes
The log file in future iRODS releases should really, _really_ have some indication that the connection is SSL-secured. The client-side should also get some notification like that. When the SSL setup is properly working, there are no indications that it _is_ working in the logs!
If the server has "irods_client_server_policy" set to "CS_NEG_REQUIRE" and the client is set to "CS_NEG_REFUSE", a non-SSL connection is made without error messages or warnings. That is to say, the server-side CS_NEG_REQUIRE is disregarded.
Setting "irods_ssl_verify_server" to "hostname" might produce errors on multi-host setups, because the hostname given for the certificate can't match both the resource server and ICAT.
Setting "irods_ssl_ca_certificate_path" isn't optional, it's a must.
Manual uses "irods_auth_scheme" to set the authentication scheme, but the correct variable name is "irods_authentication_scheme" (you won't need this if you just are interested in SSL).
Use tcpdump/wireshark to verify that your SSL setup is working.
We managed to get SSL working in our RHEL6 testing environment. It took some time, so I'm writing some of the process here to help future iRODS 4.X SSL pioneers set up their testing environments. Some of the things mentioned in '3)' should really be in the new 4.1.0 manual, as that would help a lot.
1) Creating testing certificates
First things first. For use in our testing environment, we had to act as our own certificate authority to be able to get multi-host self-signed certificates to work with iRODS. Here are all the steps to create working testing certificates for use with iRODS 4.X:
# Generate a private key
$ openssl genrsa -des3 -out testing_env.key 2048
# Generate CSR
$ openssl req -new -x509 -key testing_env.key -out testing_env.csr -days 730
...
(answer the questions what you want to)
...
# Remove password from key
$ cp testing_env.key testing_env.key.orig
$ openssl rsa -in testing_env.key.orig -out testing_env.key
# Create extension file
$ cat testing_env_extension
[ testing_env ]
nsCertType = server
keyUsage = digitalSignature,nonRepudiation,keyEncipherment
extendedKeyUsage = serverAuth
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
subjectAltName = @testing_env_hosts
[ testing_env_hosts ]
DNS.1 = testing_host_1.company.com
DNS.2 = testing_host_2.company.com
DNS.3 = testing_host_3.company.com
# Be a new CA (for testing environments)
$ openssl genrsa -des3 -out testing_CA.key 2048
$ openssl req -new -x509 -key testing_CA.key -out testing_CA.crt -days 730
...
(answer the questions what you want to)
...
# Remove password from key
$ cp testing_CA.key testing_CA.key.orig
$ openssl rsa -in testing_CA.key.orig -out testing_CA.key
# Sign the server certificate request with the CA
$ openssl x509 -req -days 730 -in testing_env.csr -CA testing_CA.crt -CAkey testing_CA.key -CAcreateserial -out server.cer -extfile testing_env_extension -extensions testing_env
# Create chain.pem
$ cat server.cer testing_CA.crt > chain.pem
# Create Diffie-Hellman params
$ openssl dhparam -2 -out dhparams.pem 2048
# Copy the files to their respective locations
See 2) configurations for suggested file locations (note: all the files and file locations are the same across servers).
2) SSL configurations
Lets say testing_host_1.company.com is a laptop client with icommands, testing_host_2.company.com is a resource server, and testing_host_3.company.com is an ICAT server.
testing_host_1.company.com:~/.irods/irods_environment.json
Add the following lines:
...
...
"irods_client_server_policy": "CS_NEG_REQUIRE",
"irods_encryption_key_size": 32,
"irods_encryption_salt_size": 8,
"irods_encryption_num_hash_rounds": 16,
"irods_encryption_algorithm": "AES-256-CBC",
"irods_default_hash_scheme": "SHA256",
"irods_match_hash_policy": "not_strict",
"irods_ssl_ca_certificate_file": "/etc/irods/chain.pem",
"irods_ssl_ca_certificate_path": "/etc/irods/certs",
"irods_ssl_verify_server": "cert",
...
...
Ensure all the files mentioned above exist and are readable by the 'irods' system user. Create the directory "irods_ssl_ca_certificate_path" points to (/etc/irods/certs is suggested). Directory can be empty, but it must exist. Otherwise you will get an error.
Do 'iexit full && iinit'.
testing_host_2.company.com:~/.irods/irods_environment.json AND testing_host_3.company.com:~/.irods/irods_environment.json
Add the following lines:
...
...
"irods_client_server_policy": "CS_NEG_REQUIRE",
"irods_encryption_key_size": 32,
"irods_encryption_salt_size": 8,
"irods_encryption_num_hash_rounds": 16,
"irods_encryption_algorithm": "AES-256-CBC",
"irods_default_hash_scheme": "SHA256",
"irods_match_hash_policy": "not_strict",
"irods_ssl_certificate_chain_file": "/etc/irods/chain.pem",
"irods_ssl_certificate_key_file": "/etc/irods/testing_env.key",
"irods_ssl_dh_params_file": "/etc/irods/dhparams.pem",
"irods_ssl_ca_certificate_file": "/etc/irods/chain.pem",
"irods_ssl_ca_certificate_path": "/etc/irods/certs",
"irods_ssl_verify_server": "cert",
...
...
Ensure all the files mentioned above exist and are readable by the 'irods' system user. Create the directory that "irods_ssl_ca_certificate_path" points to (/etc/irods/certs is suggested). Directory can be empty, but it must exist. Otherwise you will get an error.
Do 'iexit full && iinit'.
3) Some notes
The log file in future iRODS releases should really, _really_ have some indication that the connection is SSL-secured. The client-side should also get some notification like that. When the SSL setup is properly working, there are no indications that it _is_ working in the logs!
If the server has "irods_client_server_policy" set to "CS_NEG_REQUIRE" and the client is set to "CS_NEG_REFUSE", a non-SSL connection is made without error messages or warnings. That is to say, the server-side CS_NEG_REQUIRE is disregarded.
Setting "irods_ssl_verify_server" to "hostname" might produce errors on multi-host setups, because the hostname given for the certificate can't match both the resource server and ICAT.
Setting "irods_ssl_ca_certificate_path" isn't optional, it's a must.
Manual uses "irods_auth_scheme" to set the authentication scheme, but the correct variable name is "irods_authentication_scheme" (you won't need this if you just are interested in SSL).
Use tcpdump/wireshark to verify that your SSL setup is working.
-- Taneli Riitaoja / CSC
Terrell Russell
Mar 4, 2015, 11:47:17 PM3/4/15
to irod...@googlegroups.com
Taneli,
This really is tremendous. Thank you.
We'll incorporate a lot of it into our next updates for the manual.
Terrell
tuxwi...@gmail.com
Mar 9, 2015, 5:51:20 PM3/9/15
to irod...@googlegroups.com
Hi Terrel,
My 2cts,
I would expect the servers to accept anything that is resolvable through the chain. Since certificates are usually host specific, it would not make sense to share one certificate over all servers within a zone.
Even in the case of self signed certificates you can use a CA though, so as long as the CA certificate is in the chain this should just work right? Doesn't it already?
With kind regards,
Jeroen Roodhart
My 2cts,
I would expect the servers to accept anything that is resolvable through the chain. Since certificates are usually host specific, it would not make sense to share one certificate over all servers within a zone.
Even in the case of self signed certificates you can use a CA though, so as long as the CA certificate is in the chain this should just work right? Doesn't it already?
With kind regards,
Jeroen Roodhart
taffel...@gmail.com
Mar 12, 2015, 5:10:09 AM3/12/15
to irod...@googlegroups.com
Hi,
we ran into an additional little bug. The setup to reproduce the bug is related to the previous things I mentioned, and that post is quite long, so I won't make a github issue of this. It's very probable no one else will ever encounter this bug (unless they also do automated testing), but if they do maybe this will help.
Requirements for the bug to occur:
1) If (as mentioned previously) the server is set to "CS_NEG_REQUIRE" and client is set to "CS_NEG_REFUSE", the server's CS_NEG_REQUIRE is disregarded and a non-SSL connection is made between the client and the server.
2) The core.re setting "acSetNumThreads" on the server-side is set to a number greater than 1, for example 4.
3) There is a compound replication resource that is the default resource.
To reproduce, try to upload a file (from client to server) with a size of over 32MB (to activate the iRODS parallel transfer functionality):
$ iput my_file_that_is_over_32MB_in_size.dat
File transfer is successful, but replication fails. Server-side log shows:
Mar 12 10:16:37 pid:4360 NOTICE: _partialDataPut:Bytes written 330144 don't match read 4194304
Mar 12 10:16:37 pid:4360 NOTICE: _partialDataPut:Bytes written 324352 don't match read 4194304
Mar 12 10:16:37 pid:4360 ERROR: [-] iRODS/lib/core/src/procApiRequest.cpp:266:readAndProcApiReply : status [SYS_HEADER_READ_LEN_ERR] errno [] -- message []
[-] iRODS/lib/core/src/sockComm.cpp:197:readMsgHeader : status [SYS_HEADER_READ_LEN_ERR] errno [] -- message [failed to call 'read header']
[-] libssl.cpp:593:ssl_read_msg_header : status [SYS_HEADER_READ_LEN_ERR] errno [] -- message [read 0 expected 4]
This is most likely caused by the original illogical behaviour of the CS_NEG_REFUSE. When both sides agree on using SSL or agree on not using SSL, this bug does not occur. If required, I'll do a more detailed "how to reproduce", but I guess this quirk will get fixed as a bonus if you fix the CS_NEG_REFUSE bug/feature.
we ran into an additional little bug. The setup to reproduce the bug is related to the previous things I mentioned, and that post is quite long, so I won't make a github issue of this. It's very probable no one else will ever encounter this bug (unless they also do automated testing), but if they do maybe this will help.
Requirements for the bug to occur:
1) If (as mentioned previously) the server is set to "CS_NEG_REQUIRE" and client is set to "CS_NEG_REFUSE", the server's CS_NEG_REQUIRE is disregarded and a non-SSL connection is made between the client and the server.
2) The core.re setting "acSetNumThreads" on the server-side is set to a number greater than 1, for example 4.
3) There is a compound replication resource that is the default resource.
To reproduce, try to upload a file (from client to server) with a size of over 32MB (to activate the iRODS parallel transfer functionality):
$ iput my_file_that_is_over_32MB_in_size.dat
File transfer is successful, but replication fails. Server-side log shows:
Mar 12 10:16:37 pid:4360 NOTICE: _partialDataPut:Bytes written 330144 don't match read 4194304
Mar 12 10:16:37 pid:4360 NOTICE: _partialDataPut:Bytes written 324352 don't match read 4194304
Mar 12 10:16:37 pid:4360 ERROR: [-] iRODS/lib/core/src/procApiRequest.cpp:266:readAndProcApiReply : status [SYS_HEADER_READ_LEN_ERR] errno [] -- message []
[-] iRODS/lib/core/src/sockComm.cpp:197:readMsgHeader : status [SYS_HEADER_READ_LEN_ERR] errno [] -- message [failed to call 'read header']
[-] libssl.cpp:593:ssl_read_msg_header : status [SYS_HEADER_READ_LEN_ERR] errno [] -- message [read 0 expected 4]
This is most likely caused by the original illogical behaviour of the CS_NEG_REFUSE. When both sides agree on using SSL or agree on not using SSL, this bug does not occur. If required, I'll do a more detailed "how to reproduce", but I guess this quirk will get fixed as a bonus if you fix the CS_NEG_REFUSE bug/feature.
-- Taneli Riitaoja / CSC
Terrell Russell
Mar 24, 2015, 11:29:25 PM3/24/15
to irod...@googlegroups.com
Jeroen and Taneli,
I have linked the issue at https://github.com/irods/irods/issues/2575 back to this thread - so we should not lose the possible connection.
We currently agree, Jeroen, that with all the configuration correct, it *should* work - but we have not yet demonstrated this in a controlled test. Our automated topology testing is now online, and we're deploying SSL this week or next.
Thank you again,
Terrell
Hurng-Chun LEE
Apr 8, 2015, 10:36:23 AM4/8/15
to irod...@googlegroups.com
Hi Terell,
While investigating the possibility of data encryption during iput/iget in iRODS 4.0.3, I ran into this post. Indeed the data encryption is working when both server and client are configured with "CS_NEG_REQUIRE" policy (and thus the SSL is enabled).
However, in the current situation, the client can turn off SSL and consequently the data encryption by setting the policy to "CS_NEG_REFUSE". It's fine for me, but I wonder if there is (or will be) a way on the server to enforce SSL and data encryption (e.g. rejecting clients with "CS_NEG_REFUSE" policy)?
My question seems to be related to one of the point observed by Taneli.
1) If (as mentioned previously) the server is set to "CS_NEG_REQUIRE" and client is set to "CS_NEG_REFUSE", the server's CS_NEG_REQUIRE is disregarded and a non-SSL connection is made between the client and the server.
Cheers, Hong
Terrell Russell於 2015年3月25日星期三 UTC+1上午4時29分25秒寫道：
Ben Keller
Apr 8, 2015, 12:07:57 PM4/8/15
to irod-chat
The iRODS SSL settings can be tricky.
If you want iRODS servers to require SSL connections, you will need to edit the contents of /etc/irods/core.re:Find the line: acPreConnect(*OUT) { *OUT="CS_NEG_DONT_CARE"; }
and change OUT to "CS_NEG_REQUIRE"
The environment variable irodsClientServerPolicy is a client setting. iRODS servers act as clients when connecting to other iRODS servers (e.g. when acting as request intermediaries). When acting as clients, iRODS servers use the settings in the service account's ~/.irods/.irodsEnv . So when you were setting that variable to "CS_NEG_REQUIRE", that was making sure that iRODS servers, when acting as clients and connecting to other iRODS servers, would use SSL. Setting that variable was not forcing iRODS servers, when acting as servers and receiving client connections, to only accept clients that were using SSL.
Hurng-Chun LEE
Apr 8, 2015, 3:31:45 PM4/8/15
to irod...@googlegroups.com
Hi Ben,
Ben Keller於 2015年4月8日星期三 UTC+2下午6時07分57秒寫道：
Thanks for the suggested configuration. Indeed, it works. But then I realised that this setting on the server side can simply break all Jargon-based clients. Unfortunately, I didn't manage to find any thing about setting "CS_NEG_REQUIRE" in Jargon. Do you maybe know something about it?
Cheers, Hong
Ben Keller於 2015年4月8日星期三 UTC+2下午6時07分57秒寫道：
Conway, Mike
Apr 8, 2015, 3:51:23 PM4/8/15
to irod...@googlegroups.com
that is correct for the time being, we will be adding ssl to jargon in a coming release
MC
From: irod...@googlegroups.com [irod...@googlegroups.com] on behalf of Hurng-Chun LEE [hclee...@gmail.com]
Sent: Wednesday, April 08, 2015 3:31 PM
To: irod...@googlegroups.com
Subject: Re: [iROD-Chat:13524] iRODS 4.X SSL configuration between client, resource server and ICAT
Sent: Wednesday, April 08, 2015 3:31 PM
To: irod...@googlegroups.com
Subject: Re: [iROD-Chat:13524] iRODS 4.X SSL configuration between client, resource server and ICAT
Reply all
Reply to author
Forward
0 new messages