## 5 Evaluation Approach
### Analysis of Feature Models and Diagnosis of Configurations
In the case of the fourth invalid configuration, the _Port_ feature has not been chosen, which corresponds to the _TCP_ port number used by the HTTP Connector component of an Apache Tomcat server to create a server socket for incoming connections. This configuration is invalid since, as indicated in the Apache Tomcat documentation, if the Tomcat port is not configured, it will select a free random port, a situation that should only occur in embedded and test applications. In this way, in the configuration diagnosis it is indicated that in order to correct it, this characteristic must be selected. In the case of _SSL/TLS_ configurations (cf., Table 5), there are also four erroneous settings. For the feature of _Authentication_, no mechanism has been selected in the first wrong configuration, and the suggested diagnosis is to select _ECDSA_ or _RSA_Auth_. In the second wrong configuration, _ECDHE_ has been selected as a feature of _KeyExchange_, but that an elliptical curve (_Curve_) is required, and the configuration also sets the size of the key (_KeySize_) to 3072. The suggested diagnosis includes two possibles solutions: (1) deselect _ECDHE_ or (2) to select features _RSA_Auth_ and _DHE_ since by selecting these features the configuration is compatible with a key size of 3072. In the case of the third invalid configuration, _SRP_ has been chosen as the key exchange protocol. This configuration is invalid because, as indicated in the TLS definition (RFC 5246), RSA and DH must be used for key exchange. In this way, the configuration diagnosis indicates that in order to correct it, _SRP_ must be deselected and _DHE_ must be chosen. In the case of the fourth invalid configuration, 1024 has been chosen as the key size. This configuration is invalid because, although as indicated in the TLS definition (RFC 5246) the use of any key size is allowed, this size is not considered secure. In this way, the configuration diagnosis indicates that in order to correct it, the chosen size must be deselected and one of the recommended ones must be chosen. The cases of _Linux_ and _Android_ are shown in Tables 6 and 7 respectively. In the case of the first invalid configuration of _Linux_, the feature _SECURITY_NETWORK_XFRM_ is selected. This feature enables the XFRM (IPSec) networking security hooks. Nevertheless, this is not possible to be configured without previously selecting the _SECURITY_NETWORK_ flag. The security network flag enables the socket and networking security hooks. Therefore, the diagnosis recommends to deselect _SECURITY_NETWORK_XFRM_ and select _SECURITY_NETWORK_. Similarly occurs with the second invalid configuration, this configuration consists of several hardened user copy strategies (i.e., harden memory copies between the kernel and the userspace) such as _HARDENED_USERCOPY_FALLBACK_ without previously selecting the feature _HARDENED_USERCOPY_. For the third invalid configuration, _STATIC_USERMODEHELPER_PATH_ has been chosen without choosing _STATIC_USERMODEHELPER_. This configuration is invalid because this parameter defines the path to the static user mode auxiliary binary, but you must also include the _STATIC_USERMODEHELPER_ parameter, which forces all user mode help calls to pass through a single binary. In fact, the configuration diagnosis indicates that, in order to correct the configuration this parameter must be deselected or _USERMODEHELPER_ must be chosen. In the case of the fourth invalid configuration, the parameter _SECURITY_PATH_ has been selected without selecting _SECURITY_. This configuration is invalid because this parameter, which enables security hooks for path-based access control, also requires you must choose the _SECURITY_ parameter, which enables different security models. In fact, in the configuration diagnosis, it is indicated that in order to correct it, this parameter must be deselected or _SECURITY_ must be chosen.