It’s due to an security fix of OpenJDK 1.6.0 added by Redhat. Here is excerpt
of [RHSA-2011:1380-01] Critical: java-1.6.0-openjdk security update(
https://www.redhat.com/archives/rhsa-announce/2011-October/msg00011.html)
A flaw was found in the way the SSL 3 and TLS 1.0 protocols used block
ciphers in cipher-block chaining (CBC) mode. An attacker able to perform a
chosen plain text attack against a connection mixing trusted and untrusted
data could use this flaw to recover portions of the trusted data sent over
the connection. (CVE-2011-3389)
Note: This update mitigates the CVE-2011-3389 issue by splitting the first
application data record byte to a separate SSL/TLS protocol record. This
mitigation may cause compatibility issues with some SSL/TLS implementations
and can be disabled using the jsse.enableCBCProtection boolean property.
This can be done on the command line by appending the flag
"-Djsse.enableCBCProtection=false" to the java command.
To our knowledge, there are two condition need to be met to trigger this bug:
1. Using old keystore generated by mgmt. server 2.2.8, which is signed with
SHA1withDSA. Any version later than 2.2.8 would generate keystore signed with
SHA1withRSA. RSA one seems fine with us so far.
2. Use OpenJDK >=1.6.0.
The reason is, due to the security fix above, the assumption that one packet
would contain only one SSL record is broken. The decrypted data maybe only
contained the first byte of original application data. Then result in buffer
underflow when mgmt server want to read more from it.
To workaround it, according to the message above, add
"-Djsse.enableCBCProtection=false" to tomcat6.conf JAVA_OPTS line would work.
Notice the parameter would only work with latest version of OpenJDK, so simply
add it to the all setup would not work.
This patch provided a fix for it.
status 11904: resolved fixed
Changes:
- Added a new interface 'PluggableService'
- Any component that can be packaged separately from cloudstack, can implement this interface and provide its own property file listing the API commands the component supports
- As an example have made VirtualNetworkApplianceService pluggable and a new configureRouter command is added
- ComponentLocator reads all the pluggable service from componentLibrary or from components.xml and instantiates the services.
- As an example, DefaultComponentLibrary adds the pluggable service 'VirtualNetworkApplianceService'
- Also components.xml.in has an entry to show how a pluggable service can be added, but it is commented out.
- APIServer now reads the commands for each pluggable service and when a command for such a service is called, APIServer sets the required instance of the pluggable service in the coomand.
- To do this a new annotation '@PlugService' is added that is processed by APIServer. This eliminates the dependency on the BaseCmd to instantiate the service instances.
move all listxxx interface from HostDao to managers(ResourceManager, SecondaryStorageVmManager etc) with decent name using SearchCriteria2
or direct call SearchCriteria2 on demand
1) Added new apis: createFirewallRule, deleteFirewallRule, listFirewallRules
2) Modified existing apis - added boolean openFirewall parameter to createPortForwardingRule/createIpForwardingRule/createRemoteAccessVpn. If parameter is set to true, open firewall on the domR before creating an actual PF rule there
Modified backend calls appropriately.
3) Schema changes for firewall_rules table:
* startPort/endPort can be null now
* added icmp_type, icmp_code fields (can be not null only when protocol is icmp)
4) Added new manager - FirewallManagerImpl
Conflicts:
api/src/com/cloud/api/BaseCmd.java
client/tomcatconf/commands.properties.in
server/src/com/cloud/api/ApiResponseHelper.java
server/src/com/cloud/configuration/DefaultComponentLibrary.java
server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java
server/src/com/cloud/network/rules/RulesManagerImpl.java
1) Added new apis: createFirewallRule, deleteFirewallRule, listFirewallRules
2) Modified existing apis - added boolean openFirewall parameter to createPortForwardingRule/createIpForwardingRule/createRemoteAccessVpn. If parameter is set to true, open firewall on the domR before creating an actual PF rule there
Modified backend calls appropriately.
3) Schema changes for firewall_rules table:
* startPort/endPort can be null now
* added icmp_type, icmp_code fields (can be not null only when protocol is icmp)
4) Added new manager - FirewallManagerImpl
implement pool-wise VM sync,
For XenServer, VM fullSync is pool-wise now, VM deltaSync is still per host
Conflicts:
server/src/com/cloud/vm/VirtualMachineManagerImpl.java
Use a new target "system-integrity-checker" in components.xml/components-premium.xml.
All checkers must be explicitly specified in XML file, they will execute before any components load
status 10860: resolved fixed
