| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This commit adds the initial SSL support for http_client which can be
used for sending asynchronous Events/MetricReports to subscribed Event
Listener servers over secure channel.
Current implementation of http client only works for http protocol.
With current implementation, http client can be configured to work
with secure http (HTTPS). As part of implementation it adds the SSL
handshake mechanism and enforces the peer ceritificate verification.
The http-client uses the cipher suites which are supported by mozilla
browser and as recommended by OWASP. For better security enforcement
its disables the SSLv2, SSLv3, TLSv1, TLSv1.1 as described in below
OWASP cheetsheet.
It is validated with RootCA certificate(PEM) for now. Adding support
for different certificates can be looked in future as need arises.
[1]: https://cheatsheetseries.owasp.org/cheatsheets/TLS_Cipher_String_Cheat_Sheet.html
Tested:
- Created new subscription with SSL destination(https) and confirmed
that events are seen on EventListener side.
URI: /redfish/v1/EventService/Subscriptions
Method: POST
Body:
{
"Context": "CustomText",
"Destination": "https://<IP>:4000/service/collector/event_logs",
"EventFormatType": "Event",
"DeliveryRetryPolicy": "RetryForever",
"Protocol": "Redfish"
}
- Unit tested the non-SSL connection by disabling the check in code
(Note: EventService blocks all Non-SSL destinations). Verified that
all events are properly shown on EventListener.
URI: /redfish/v1/EventService/Subscriptions
Method: POST
Body:
{
"Context": "CustomText",
"Destination": "http://<IP>:4001/service/collector/event_logs",
"EventFormatType": "Event",
"Protocol": "Redfish"
}
- Combined above two tests and verified both SSL & Non-SSL work fine in
congention.
- Created subscription with different URI paths on same IP, Port and
protocol and verified that events sent as expected.
Change-Id: I13b2fc942c9ce6c55cd7348aae1e088a3f3d7fd9
Signed-off-by: AppaRao Puli <apparao.puli@intel.com>
Signed-off-by: Ed Tanous <edtanous@google.com>
|
|
clang-tidy readability checks are overall a good thing, and help us to
write consistent and readable code, even if it doesn't change the
result.
All changes done by the robot.
Tested: Code compiles, inspection only (changes made by robot)
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: Iee4a0c74a11eef9f158f0044eae675ebc518b549
|
|
When CI tests are run locally on machine without OpenSSL 3.0, there are
some warnings during clang-tidy scan. They are related to unsupported
c-style code (implicit bool/int conversion, casting, and varagrs
functions). This change is fixing all of them, without changing
functionality.
Testing done:
- running docker image with UTs on local Ubuntu machine with SSL 1.1 is
passing all tests, and no clang errors are reported.
Signed-off-by: Szymon Dompke <szymon.dompke@intel.com>
Change-Id: I5ec91db8f02f487786811afad77080137bab3c9a
|
|
These checks ensure that we're not implicitly converting ints or
pointers into bools, which makes the code easier to read.
Tested:
Ran series through redfish service validator. No changes observed.
UUID failing in Qemu both before and after.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I1ca0be980d136bd4e5474341f4fd62f2f6bbdbae
|
|
const_cast is an anti pattern. There are a few places we need to do it
for interacting with C APIs, so enable the checks, and ignore the
existing uses.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: If1748213992b97f5e3e04cf9b86a6fcafbb7cf06
|
|
We seem to use reinterpret cast in a few cases unfortunately. For the
moment, simply ignore most of them, and make it so we don't get more.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: Ic860cf922576b18cdc8d51d6132f5a9cbcc1d9dc
|
|
clang-tidy added cppcoreguidelines-init-variables as a check, which is
something we already enforce to some extent, but getting CI to enforce
it will help reviews move faster.
Tested: Code compiles. Noop changes.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I7e10950de617b1d3262265572b1703f2e60b69d0
|
|
CI is failing on master due to clang-tidy failing for:
error: invalid case style for variable 'pkey_ctx'
[readability-identifier-naming,-warnings-as-errors]
EVP_PKEY_CTX* pkey_ctx =
^~~~~~~~
pkeyCtx
Change variable name to make clang-tidy happy.
This was introduced in 145bb764.
Tested: None. CI passing will validate clang-tidy passing.
Change-Id: Iedd8a40a871940066743ff8698dad53bfb0407c0
Signed-off-by: Gunnar Mills <gmills@us.ibm.com>
|
|
Loading and checking of keys is one area where OpenSSL 1.0 and 3.0 are
not compatible. Many of the functions currently used in the
ssl_key_handler are deprecated in 3.0, but the APIs necessary for
conversion also do not exist in 1.0. Until OpenSSL 3.0 is widely used
in Linux distributions we therefore need to support both APIs.
Add a #define on the OPENSSL_VERSION_NUMBER to identify 3.x (or greater)
support and switch between the two API sets.
Tested: Added to a Yocto test build for the subtree update that
includes OpenSSL 3.x and confirmed Romulus QEMU test is successful.
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I22bc77753bb32d1b92932f9918d64856a4e52af8
|
|
The APIs for generating an EC key for have changed between OpenSSL 1.x
and OpenSSL 3.x. Create a separate implementation for OpenSSL 3.x.
Tested: Copied code from phosphor-certificate-manager, which was
tested using unit tests, and confirmed it builds and runs when compiled
with the OpenSSL 3.x library.
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I6df0fb5429e0812763dad4a208bb914fb285fd78
|
|
bmcweb::OpenSSLGenerator is defined in include/random.hpp.
Signed-off-by: Nan Zhou <nanzhoumails@gmail.com>
Change-Id: I1d8751b49a0121526a40b885ed7f5b520640f9f0
|
|
With `BMCWEB_ENABLE_SSL`, it will cause issues with functions
that depends on `ensuressl`. Since openssl is required, that flag can
be removed for the ssl_key_handler.
prepareMutualTls() is dependent on `ensuressl` which is only available
`insecure-disable-ssl` is disable so the CI didn't catch this error.
If `insecure-disable-ssl` is enable, then `ensuressl` will be missing
and fail the bmcweb build due to prepareMutualTls().
Error example,
```
Step #1: In file included from ../git/http/http_server.hpp:3,
Step #1: from ../git/http/app.hpp:5,
Step #1: from ../git/src/webserver_main.cpp:4:
Step #1: ../git/http/http_connection.hpp: In member function 'void crow::Connection<Adaptor, Handler>::prepareMutualTls()':
Step #1: ../git/http/http_connection.hpp:99:38: error: 'ensuressl' has not been declared
Step #1: 99 | std::filesystem::path caPath(ensuressl::trustStorePath);
Step #1: | ^~~~~~~~~
Step #1: ninja: build stopped: subcommand failed.
```
Change-Id: I3c010d5042b4615623b1c043a368ba5c9cbc6b4c
Signed-off-by: Willy Tu <wltu@google.com>
|
|
Fix memory leak issue when opening the certificate file
Refer to details: https://github.com/openbmc/bmcweb/issues/195
Tested:
Check the number of open files in bmcweb via lsof command
$lsof -p {the pid of bmcweb} | grep REG |grep pem | wc -l
0
Signed-off-by: Alan Kuo <Alan_Kuo@quantatw.com>
Change-Id: Id05fc4f3e653f51c5f02212ad8f361c7e8091808
|
|
Clang tidy 11 got some really neat checks that do a much better job.
Unfortunately, this, combined with the change in how std::executors has
defined how callbacks should work differently in the past, which we
picked up in 1.73, and now in theory we have recursion in a bunch of our
IO loops that we have to break manually. In practice, this is unlikely
to matter, as there's almost a 0% chance that we go through N thousand
requests without ever starving the IO buffer.
Other changes to make this build include:
1. Adding inline on the appropriate places where declared in a header.
2. Removing an Openssl call that did nothing, as the result was
immediately overwritten.
3. Declaring the subproject dependencies as system dependencies, which
silences the clang-tidy checks for those projects.
Tested:
Code builds again, clang-tidy passes
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: Ic11b1002408e8ac19a17a955e9477cac6e0d7504
|
|
camelLower is not a type, camelBack is.
Changes were made automatically with clang-tidy --fix-errors
To be able to apply changes automatically, the only way I've found that
works was to build the version of clang/clang-tidy that yocto has, and
run the fix script within bitbake -c devshell bmcweb. Unfortunately,
yocto has clang-tidy 11, which can apparently find a couple extra errors
in tests we already had enabled. As such, a couple of those are also
included.
Tested:
Ran clang-tidy-11 and got a clean result.
Signed-off-by: Ed Tanous <ed@tanous.net>
Change-Id: I9d1080b67f0342229c2f267160849445c065ca51
|
|
- Add a hostname listener that will create a self-signed HTTPS
certificate with the appropriate subject when the BMC gets its
hostname assigned via IPMI. The "insecure-disable-ssl" must be
disabled for this feature to take effect.
Note:
- New self-signed certificate subject: C=US, O=OpenBMC, CN=${hostname}
- If the same hostname is assigned, it will not be triggered
- Only the self-signed certificate with Netscape Comment of
"Generated from OpenBMC service" will be replaced
Details about certificate key usage:
- NID_basic_constraints
The CA boolean indicates whether the certified public key may be
used to verify certificate signatures.
Refer to: https://tools.ietf.org/html/rfc5280#section-4.2.1.9
- NID_subject_alt_name
Although the use of the Common Name is existing practice, it is
deprecated and Certification Authorities are encouraged to use the
dNSName instead.
Refer to: https://tools.ietf.org/html/rfc2818#section-3.1
- NID_subject_key_identifier
The subject key identifier extension provides a means of
identifying certificates that contain a particular public key.
Refer to: https://tools.ietf.org/html/rfc5280#section-4.2.1.2
- NID_authority_key_identifier
The authority key identifier extension provides a means of
identifying the public key corresponding to the private key used
to sign a certificate.
Refer to: https://tools.ietf.org/html/rfc5280#section-4.2.1.1
- NID_key_usage
- NID_ext_key_usage
id-kp-serverAuth
-- TLS WWW server authentication
-- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment or keyAgreement
Refer to: https://tools.ietf.org/html/rfc5280#section-4.2.1.3
Refer to: https://tools.ietf.org/html/rfc5280#section-4.2.1.12
Tested:
- To test and verify the service is functionally working correctly,
we can use `openssl` and `ipmitool` to execute the following
commands:
- Assign BMC hostname
ipmitool -H $IP -I lanplus -U root -P 0penBmc -C 17 dcmi
set_mc_id_string $hostname
- Get BMC server certificate infomation
echo quit | openssl s_client -showcerts -servername $IP -connect
$IP:443
Signed-off-by: Alan Kuo <Alan_Kuo@quantatw.com>
Change-Id: I24aeb4d2fb46ff5f0cc1c6aa65984f46b0e1d3e2
|
|
Now that CI can handle clang-tidy, and a lot of the individual fixes
have landed for the various static analysis checks, lets see how close
we are.
This includes bringing a bunch of the code up to par with the checks
that require. Most of them fall into the category of extraneous else
statements, const correctness problems, or extra copies.
Tested:
CI only. Unit tests pass.
Signed-off-by: Ed Tanous <ed@tanous.net>
Change-Id: I9fbd346560a75fdd3901fa40c57932486275e912
|
|
Change-Id: Iafbd209fe2cb4503df995536587d8a80bd887a74
Signed-off-by: Gunnar Mills <gmills@us.ibm.com>
|
|
This is from openbmc/docs/style/cpp/.clang-format
Other OpenBMC repos are doing the same.
Tested: Built and validator passed.
Change-Id: Ief26c755c9ce012823e16a506342b0547a53517a
Signed-off-by: Gunnar Mills <gmills@us.ibm.com>
|
|
In code that is clearly working with EC keys, but once was used for RSA
keys, remove the incorrectly named RSA names and comments to reduce
confusion.
Change-Id: Ide6909bb80fea18bfc51bd3376ae8a51be6baa05
Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>
|
|
prime256v1 is okay for now, but secp384r1 is more future-proof (gives us
a couple more years) and in this case does not really have any
drawbacks.
Tested: Checked to see that a new secp384r1 key is generated on first
boot and the generate CSR redfish option works.
Change-Id: I334fc56db3dd55058a4c6780f8966bcc48d8f816
Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>
|
|
This makes some browswers fail to login without a
certificate, it needs to stay disabled.
Introduced here:
https://github.com/openbmc/bmcweb/commit/55e43f69#diff-f34027492b16c1b7a880248323fe4fd8R316
Tested: Cert was not required in Chrome on Windows
Change-Id: I27e60e73784d04e14b9b1495ebd1399ad4ab96ab
Signed-off-by: James Feist <james.feist@linux.intel.com>
|
|
This disables ssl renegotiaion based on the potential
DOS attack here: https://www.cvedetails.com/cve/CVE-2011-1473/
Tested: testssl shows it as disabled
https://github.com/drwetter/testssl.sh
validator passed
Fixes https://github.com/openbmc/openbmc/issues/3624
Change-Id: I4bfbd770d25ba5d1a7292421f1ccad2b2e73d3a6
Signed-off-by: James Feist <james.feist@linux.intel.com>
|
|
This was an automatic change made by clang-tidy. It moves all uses of
NULL to nullptr, which are equivalent, but nullptr is prefered.
Tested: Code compiles.
Signed-off-by: Ed Tanous <ed.tanous@intel.com>
Change-Id: I9526599b222693c9723a69934b599c7a5b5d1fbf
|
|
Implemented TLS based user auth. It utilizes certificates stored by
Phosphor Certificate Manager in storage mode, to verify that user
that tries to log in, has a certificate signed by a trusted CA.
More about this can be read in redfish-tls-user-authentication.md design
document.
Tested that it does not break current authentication methods, when not
using TLS Auth - user should not see difference between versions. TLS Auth
itself allows user in when certificate is signed by trusted CA and valid, and
stops working immediatley after it is removed. User is not let in when provided
certificate is not between notBefore and notAfter dates. Session is tested to
not be created when user does not exist in the system (courtesy of earlier
UserManagement usage commits).
Signed-off-by: Kowalski, Kamil <kamil.kowalski@intel.com>
Change-Id: I6bcaff018fe3105f77d3c10f69765e0011af8dab
Signed-off-by: Zbigniew Kurzynski <zbigniew.kurzynski@intel.com>
|
|
using the list of warnings from here:
https://github.com/lefticus/cppbestpractices/blob/e73393f25a85f83fed7399d8b65cb117d00b2231/02-Use_the_Tools_Available.md#L100
Seems like a good place to start, and would improve things a bit
type-wise. This patchset attempts to correct all the issues in one
shot.
Tested:
It builds. Will test various subsystems that have been touched
Signed-off-by: Ed Tanous <ed.tanous@intel.com>
Change-Id: I588c26440e5a97f718a0f0ea74cc84107d53aa1e
|
|
Currently, bmcweb is generating self signed certificate when uploaded
certificate is not in trust-chain while validating that certificate.
As per design direction, bmcweb and Certificate Manager should ignore
trust chain related errors and same feature addressed in certificate
manager.
Reference change id from Certificate Manager:
https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-certificate-manager/+/13875
With this change, the user can upload self signed CA certificate
without Root CA-Certificate in certificate store and bmcweb won't generate
self signed certificate when uploaded certificate is not in
trust-chain.
Trust chain error info:
X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT
X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN
X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY
X509_V_ERR_CERT_UNTRUSTED
X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE
Change-Id: Ieedd602541d6d5284be3e22ffd5db3ee875065fe
Signed-off-by: Ramesh Iyyar <rameshi1@in.ibm.com>
|
|
Certificate reading is failed if Key and Certificate in different order
Git Issue ID:
- https://github.com/openbmc/bmcweb/issues/91
Root Cause:
In uploaded certificate the order is in CSR and then RSA, due
to this certificate reading is failed when same file pointer are used
for read key and certificate.
Solution:
Setting file pointer to point beginning of the file to avoid
key and certificate order error and it will support both order.
Tested By:
- Uploaded the certificate by changing component order.
curl -c cjar -b cjar -k -H "X-Auth-Token: $bmc_token" -H
"Content-Type: application/octet-stream" -X POST -T cert.pem
https://${bmc}/redfish/v1/Managers/bmc/NetworkProtocol/HTTPS/Certificates
Change-Id: I6f6d41e7b8a7c2f7c5ce53c5d1bbdf69189119b2
Signed-off-by: Ramesh Iyyar <rameshi1@in.ibm.com>
|
|
Implements CertificateService schema to list the actions
available.
Implements CertificateLocations schema to list the
certificates present in the system.
Implements CertificateCollection schema to upload/list
existing HTTPS certificates
Implements Certificate schema to view existing HTTPS
certificate
Cater for reloading the SSL context after a certificate
is uploaded.
Fix Certificate signature validation failure
At present bmcweb uses the certificate from "/home/root/server.pem"
the same is modified to "/etc/ssl/certs/https/server.pem" as
phosphor-certificate-manager uses the specified path to
install/replace certificates.
Bmcweb creates a self-signed certificate when certificate is not
present. Catered for creating "/etc/ssl/certs/https/" direcotry
structure so that self signed certificate is created in the path.
Implements ReplaceCertificate action of Certificate
Service for replacing existing HTTPS certificates
Cleanup of older self-signed certificate at /home/root/server.pem
1. Tested schema with validator and no issues
2. Privilege map for certificate service is not yet pubished
2. GET on /redfish/v1/CertificateService/
"CertificateService": {
"@odata.id": "/redfish/v1/CertificateService"
},
3. GET on /redfish/v1/CertificateService/CertificateLocations/
"@odata.context":
"/redfish/v1/$metadata#CertificateLocations.CertificateLocations",
"@odata.id": "/redfish/v1/CertificateService/CertificateLocations",
"@odata.type": "#CertificateLocations.v1_0_0.CertificateLocations",
"Description": "Defines a resource that an administrator can use in order to
locate all certificates installed on a given service",
"Id": "CertificateLocations",
"Name": "Certificate Locations"
4.POST on /redfish/v1/Managers/bmc/NetworkProtocol/HTTPS/Certificates
{
Returns contents of certificate
"@odata.context": "/redfish/v1/$metadata#Certificate.Certificate",
"@odata.id": "/redfish/v1/AccountService/LDAP/Certificates/1",
"@odata.type": "#Certificate.v1A_0_0.Certificate",
"Id": "1",
"Issuer": {
...
...
}
5.GET on /redfish/v1/Managers/bmc/NetworkProtocol/HTTPS/Certificates/
{
"@odata.context":
"/redfish/v1/$metadata#CertificateCollection.CertificateCollection",
"@odata.id": "/redfish/v1/Managers/bmc/NetworkProtocol/HTTPS/Certificates",
"@odata.type": "#CertificateCollection.CertificatesCollection",
"Description": "A Collection of HTTPS certificate instances",
"Members": [
{
"@odata.id":
"/redfish/v1/Managers/bmc/NetworkProtocol/HTTPS/Certificates/1"
}
],
"Members@odata.count": 1,
"Name": "HTTPS Certificate Collection"
}
6.GET on /redfish/v1/CertificateService/CertificateLocations/
{
"@odata.context":
"/redfish/v1/$metadata#CertificateLocations.CertificateLocations",
"@odata.id": "/redfish/v1/CertificateService/CertificateLocations",
"@odata.type": "#CertificateLocations.v1_0_0.CertificateLocations",
"Description": "Defines a resource that an administrator can use in order to
locate all certificates installed on a given service",
"Id": "CertificateLocations",
"Links": {
"Certificates": [
{
"@odata.id":
"/redfish/v1/Managers/bmc/NetworkProtocol/HTTPS/Certificates/1"
}
],
"Certificates@odata.count": 1
},
"Name": "Certificate Locations"
}
7.GET on /redfish/v1/Managers/bmc/NetworkProtocol/HTTPS/Certificates/1
{
"@odata.context": "/redfish/v1/$metadata#Certificate.Certificate",
"@odata.id": "/redfish/v1/Managers/bmc/NetworkProtocol/HTTPS/Certificates/1",
"@odata.type": "#Certificate.v1_0_0.Certificate",
"CertificateString":
"-----BEGINCERTIFICATE-----\n....\n-----ENDCERTIFICATE-----\n",
"CertificateType": "PEM",
"Description": "HTTPS Certificate",
"Id": "1",
"Issuer": {
}
8. Verified SSL context is reloaded after a certificate is installed.
9.curl -c cjar -b cjar -k -H "X-Auth-Token: $bmc_token" -X POST
https://${bmc}/redfish/v1/CertificateService/Actions/CertificateService.ReplaceCertificate/
-d @data_https.json
{
"@odata.context": "/redfish/v1/$metadata#Certificate.Certificate",
"@odata.id": "/redfish/v1/Managers/bmc/NetworkProtocol/HTTPS/Certificates/1",
"@odata.type": "#Certificate.v1_0_0.Certificate",
"CertificateString": "-----BEGIN CERTIFICATE----END CERTIFICATE-----\n",
"Description": "HTTPS certificate",
"Id": "1",
"Issuer": {
}
4. data_https.json file contents
{
"CertificateString": "-----BEGIN PRIVATE
KEY-----\nMIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDClW1COSab2O0W\nW0SgTzLxQ1Igl4EpbEmTK8CAQ+wI7loTDZ7sZwYdf6yc9TAs/yNKjlJljgedGszv\nbC7sPNpH4FA63kaM6TbBBKTRshwZ3myXiBOOkOBs6w6V7+c7uEPcMFge6/4W1VXD\nReMi016cnPWZsmQyGzpmPM49YNEDZBfdKZ/pLuCYc9L9t706U7FrUSGfM7swB+mC\n8NH9qMixMuWAV9SBvzUWI6p4OCmN8a/F+4lOdbPMVEUqQ0hCBCjGM4qmiy/5Ng6y\n6rKeJlUdmOSTk8ojrNGcOXKh0nRafNEQFkIuoPHt8k5B/Yw2CX6s2BoGwvF+hS03\n+z3qVSw3AgMBAAECggEBAKpe92kybRGr3/rhMrdCYRJJpZEP1nGUdN89QbGMxxAS\n0h84n9vRYNNXRKWxMNtVEWtoLdDpiNUP8Dv59yO1LFIen2DL2e3rDJv4Gu/YCS7F\nR0NuS+FaDIaRURYLFeV+MzyJv75jVvhbFlqByJxngcGS1KAcSApvOLTnrJSlPpy9\n8ec5gnDhdOUND9PaQt8xCqMs1RPpjqvrgRzMEodZoqT5v+b0K1GmsAdbSHNP2mLM\nrqtpFDefiM1YfsTHUtxQykxG2Ipd2jzJ0a8O0qmVqdXcP9J9aqLcmD/2/r96GEV6\n/5qvIBj3SRFobxCiCwfys2XOXfjz2J+BUZzGoZvKeRECgYEA518hT6mn46LhwrTI\nW+Qpi7iTJgOfeLC+Ng855VHVQFED1P3T2lfyfGDyqKI/wV1DJIJmO8iOXerSPnhi\nb7reQkyHj6ERUtuE+6BQ9oTw2QD3EEvzOK2PEH5UipbhVTDnC3fT62Vz2yb3tR8D\n2h0XVJkj/dng9p1Td5aDGMriRRMCgYEA10vTyYqBPjDIEYw/Sc9aQk2kT6x3hrRQ\ngR4xyuI31RTCRD/KpLh/7z4s11Wkr+F9CyASeLbqu6zymlLOlS5p7IUkJ/x2X027\nJWVY1SR+oF3iF3SHiP4XkOVvWOKwIVUhgTjK1+Di6i3AlwIeAOS7VCCP6W0gbnwJ\nyyAAHZ30NM0CgYAqTur4dj2NEqvVvtkkdIRkWEwQF3mByE//8qjTljM4n5fjysaC\nlrJwrAmzbHfcFAHDG1U2eWYPJnFrmvflFnauCPCBAyL308xtdtNXQNgJ1nNXN4wy\nQQp4KaGr9gseWOLm5fKKiPK2kFmbdSBvMgKiJZ6/PKg2cG5i39L5JaBaoQKBgApw\nqOJ7Du1fHDSNonwHzA6vCSq76Efl8olwV2XJNn/ks87vcPov4DRPxYjjpErLGm8x\nrPOhmxxitJj7Lv1Y9NX9VtWBjpPshwi3M2mSjXllVBNjGTdxat8h4RZkV7omEKvd\nfyicxSQp987a0W2lqdfYhGIDYrE43pi1AoxtHmx5AoGBAJSoRy62oZbW6vjfdkuf\nvVnjNfFZwuiPV/X2NT+BhNPe5ZKFtC6gGedHLaIBBD3ItRhGuHZxgWXccPjGHofi\n6DlPdp2NePJgDT2maSjGSiAcHxyXdmW+Ev27NblvAxktoTUcVqSENrKFb+Fh4FXN\nlXiJzOEwAXiP2ZFbMRyNF/MI\n-----END
PRIVATE KEY-----\n-----BEGIN
CERTIFICATE-----\nMIIDNzCCAh+gAwIBAgIJAI1Wr/fK5F0GMA0GCSqGSIb3DQEBCwUAMDIxHDAaBgNV\nBAoME29wZW5ibWMtcHJvamVjdC54eXoxEjAQBgNVBAMMCWxvY2FsaG9zdDAeFw0x\nOTAyMDExMzIyMDhaFw0yOTAxMjkxMzIyMDhaMDIxHDAaBgNVBAoME29wZW5ibWMt\ncHJvamVjdC54eXoxEjAQBgNVBAMMCWxvY2FsaG9zdDCCASIwDQYJKoZIhvcNAQEB\nBQADggEPADCCAQoCggEBAMKVbUI5JpvY7RZbRKBPMvFDUiCXgSlsSZMrwIBD7Aju\nWhMNnuxnBh1/rJz1MCz/I0qOUmWOB50azO9sLuw82kfgUDreRozpNsEEpNGyHBne\nbJeIE46Q4GzrDpXv5zu4Q9wwWB7r/hbVVcNF4yLTXpyc9ZmyZDIbOmY8zj1g0QNk\nF90pn+ku4Jhz0v23vTpTsWtRIZ8zuzAH6YLw0f2oyLEy5YBX1IG/NRYjqng4KY3x\nr8X7iU51s8xURSpDSEIEKMYziqaLL/k2DrLqsp4mVR2Y5JOTyiOs0Zw5cqHSdFp8\n0RAWQi6g8e3yTkH9jDYJfqzYGgbC8X6FLTf7PepVLDcCAwEAAaNQME4wHQYDVR0O\nBBYEFDDohRZ1+QlC3WdIkOAdBHXVyW/SMB8GA1UdIwQYMBaAFDDohRZ1+QlC3WdI\nkOAdBHXVyW/SMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBAFN0DWy6\nYPXHzidWMKKyQiJ5diqUv6LbujKOHUk+/LGSoCqcUp8NvmFDKWYP9MxjOAi9TVbs\nRGlIHBl38oSwKUayXBTY/vVeSLls90giUAOjswoRbBBQZvKyfEuFpc1zUsrhGLDC\n/6DuRt9l0DWcMcmP6Yh3jePIIwTr3bpxBGrwNLly8fPf16q4bWRIAcI3ZgLOhsrN\nLfD2kf56oYViM44d54Wa0qjuCfeTnJ46x/lo6w2kB9IzF7lwpipMU7+AG8ijDdaQ\nn8t0nADpv6tNNargLcOTTfJ0/P2PaKxwA1B88NhjlymBnNbz4epIn4T3KyysgS62\nzwqs66LPWoDerzc=\n-----END
CERTIFICATE-----",
"CertificateType": "PEM",
"CertificateUri":
{
"@odata.id":
"/redfish/v1/Managers/bmc/NetworkProtocol/HTTPS/Certificates/1"
}
}
Change-Id: I2acbf8afa06bbf7d029d4971f7ab3b3988f5f060
Signed-off-by: Marri Devender Rao <devenrao@in.ibm.com>
Signed-off-by: Ed Tanous <ed.tanous@intel.com>
|
|
Resolves openbmc/bmcweb#82
Signed-off-by: Jayanth Othayoth <ojayanth@in.ibm.com>
Change-Id: I944c1f9afe03ca58f61fdde34f83f092ff8d8ab2
|
|
A step towards upstream OpenBMC shipping free of any branding (other
than OpenBMC branding) or company references.
Tested: Did not test
Change-Id: I4fea765949ff3ad94e3cd52fedec597a77db0e79
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
Signed-off-by: Gunnar Mills <gmills@us.ibm.com>
|
|
This reverts commit 6ea007a2faec52ad62680015d2a3f00371a1e351.
Reason for revert: Reports of bmcweb seg faults.
Change-Id: I408f1bb29c2f8e427a6621cdaac8c31b847ebf06
|
|
bmcweb classically has not taken a strong opinion on warnings. With
this commit, that policy is changing, and bmcweb will invoke the best
warnings we are able to enable, and turn on -Werror for all builds.
This is intended to reduce the likelihood of hard-to-debug situations
that the compiler coulve caught early on.
Change-Id: I57474410821e82666b3a108cfd0db7d070e8900a
Signed-off-by: Ed Tanous <ed@tanous.net>
|
|
This is the second attempt to make cipher suites more restrictive. This
was previously attempted in patchset
54fd221a9139f46c7c95b4a22cc09e6e7ce4cbbc
Which caused some compatibility issues. This is the second attempt,
which does a better job. OWASP does not enable eppiliptic curve TLS 1.2
cipher suites, which at this time are required for bmcweb to function.
Previously, bmcweb was utilitizing the "mozilla compatibility" cipher
suites. This is overly lenient on broken ciphers and can cause some
issues with security reviews.
This commit also fixes our TLS logic to support _only_ TLS 1.2 and 1.3,
as only updating the cipher suites caused us to fall into TLS 1.3 only,
which broke compatibility with a lot of operating systems.
Tested by:
Ran the testssl.sh script here:
https://github.com/drwetter/testssl.sh
Observed the following in the output:
testssl.sh 3.0rc3 from https://testssl.sh/dev/
(977dc1ac4 2019-02-06 22:42:14 -- )
This program is free software. Distribution and
modification under GPLv2 permitted.
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!
Please file bugs @ https://testssl.sh/bugs/
Using "OpenSSL 1.0.2-chacha (1.0.2k-dev)" [~183 ciphers]
on Hades:/home/ed/testssl.sh/bin/openssl.Linux.x86_64
(built: "Jan 18 17:12:17 2019", platform: "linux-x86_64")
Start 2019-02-08 11:04:50 -->> 10.243.49.64:18080 (10.243.49.64) <<--
rDNS (10.243.49.64): wolfpass.jf.intel.com.
Service detected: HTTP
Testing protocols via sockets except NPN+ALPN
SSLv2 not offered (OK)
SSLv3 not offered (OK)
TLS 1 not offered
TLS 1.1 not offered
TLS 1.2 offered (OK)
TLS 1.3 offered (OK): final
NPN/SPDY not offered
ALPN/HTTP2 not offered
Testing cipher categories
NULL ciphers (no encryption) not offered (OK)
Anonymous NULL Ciphers (no authentication) not offered (OK)
Export ciphers (w/o ADH+NULL) not offered (OK)
LOW: 64 Bit + DES, RC[2,4] (w/o export) not offered (OK)
Triple DES Ciphers not offered (OK)
128 Bit ciphers (SEED, IDEA, 128 Bit CBC) offered
High encryption (AES/Aria/Camellia, !AEAD) offered (OK)
Strong encryption (AEAD ciphers) offered (OK)
Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4
PFS is offered (OK) TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-SHA384 ECDHE-ECDSA-CHACHA20-POLY1305 TLS_AES_128_GCM_SHA256
ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-SHA256
Elliptic curves offered: prime256v1 secp384r1 secp521r1 X25519 X448
Testing server preferences
Has server cipher order? yes (OK) -- only for < TLS 1.3
Negotiated protocol TLSv1.3
Negotiated cipher TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
Cipher order
TLSv1.2: ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES256-SHA384 ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-SHA256
TLSv1.3: TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256
Testing server defaults (Server Hello)
TLS extensions (standard) "renegotiation info/#65281" "EC point formats/#11" "session ticket/#35" "supported versions/#43"
"key share/#51" "supported_groups/#10" "max fragment length/#1" "encrypt-then-mac/#22"
"extended master secret/#23"
Session Ticket RFC 5077 hint 7200 seconds, session tickets keys seems to be rotated < daily
SSL Session ID support yes
Session Resumption Tickets: yes, ID: no
TLS clock skew Random values, no fingerprinting possible
Signature Algorithm ECDSA with SHA256
Server key size EC 256 bits
Server key usage --
Server extended key usage --
Serial / Fingerprints 669B86F0 / SHA1 0F6BF7C8F1AB59767FCA372A88F7F5457CFE00FB
SHA256 1D8C3AC5BA670C8C4EE8F5A76C8597226D89744510A4998B1A7888EF566256E5
Common Name (CN) testhost
subjectAltName (SAN) missing (NOT ok) -- Browsers are complaining
Issuer self-signed (NOT ok)
Trust (hostname) certificate does not match supplied URI
Chain of trust NOT ok (self signed)
EV cert (experimental) no
"eTLS" (visibility info) not present
Certificate Validity (UTC) 3648 >= 60 days (2019-02-07 10:23 --> 2029-02-04 10:23)
# of certificates provided 1
Certificate Revocation List --
OCSP URI --
NOT ok -- neither CRL nor OCSP URI provided
OCSP stapling not offered
OCSP must staple extension --
DNS CAA RR (experimental) not offered
Certificate Transparency --
Testing HTTP header response @ "/"
HTTP Status Code 200 OK
HTTP clock skew -83092 sec from localtime
Strict Transport Security 365 days=31536000 s, includeSubDomains, preload
Public Key Pinning --
Server banner iBMC
Application banner --
Cookie(s) (none issued at "/")
Security headers X-Frame-Options DENY
X-XSS-Protection 1; mode=block
X-Content-Type-Options nosniff
Content-Security-Policy default-src 'self'
X-UA-Compatible IE=11
Reverse Proxy banner --
Testing vulnerabilities
Heartbleed (CVE-2014-0160) not vulnerable (OK), no heartbeat extension
CCS (CVE-2014-0224) not vulnerable (OK)
Ticketbleed (CVE-2016-9244), experiment. not vulnerable (OK), reply empty
ROBOT Server does not support any cipher suites that use RSA key transport
Secure Renegotiation (CVE-2009-3555) not vulnerable (OK)
Secure Client-Initiated Renegotiation VULNERABLE (NOT ok), DoS threat
CRIME, TLS (CVE-2012-4929) not vulnerable (OK)
BREACH (CVE-2013-3587) potentially NOT ok, uses gzip HTTP compression. - only supplied "/" tested
Can be ignored for static pages or if no secrets in the page
POODLE, SSL (CVE-2014-3566) not vulnerable (OK)
TLS_FALLBACK_SCSV (RFC 7507) No fallback possible, no protocol below TLS 1.2 offered (OK)
SWEET32 (CVE-2016-2183, CVE-2016-6329) not vulnerable (OK)
FREAK (CVE-2015-0204) not vulnerable (OK)
DROWN (CVE-2016-0800, CVE-2016-0703) not vulnerable on this host and port (OK)
no RSA certificate, thus certificate can't be used with SSLv2 elsewhere
LOGJAM (CVE-2015-4000), experimental not vulnerable (OK): no DH EXPORT ciphers, no DH key detected with <= TLS 1.2
BEAST (CVE-2011-3389) no SSL3 or TLS1 (OK)
LUCKY13 (CVE-2013-0169), experimental potentially VULNERABLE, uses cipher block chaining (CBC) ciphers with TLS. Check patches
RC4 (CVE-2013-2566, CVE-2015-2808) no RC4 ciphers detected (OK)
Testing 370 ciphers via OpenSSL plus sockets against the server, ordered by encryption strength
Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (IANA/RFC)
-----------------------------------------------------------------------------------------------------------------------------
x1302 TLS_AES_256_GCM_SHA384 ECDH 253 AESGCM 256 TLS_AES_256_GCM_SHA384
x1303 TLS_CHACHA20_POLY1305_SHA256 ECDH 253 ChaCha20 256 TLS_CHACHA20_POLY1305_SHA256
xc02c ECDHE-ECDSA-AES256-GCM-SHA384 ECDH 521 AESGCM 256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
xc024 ECDHE-ECDSA-AES256-SHA384 ECDH 521 AES 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
xcca9 ECDHE-ECDSA-CHACHA20-POLY1305 ECDH 521 ChaCha20 256 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
x1301 TLS_AES_128_GCM_SHA256 ECDH 253 AESGCM 128 TLS_AES_128_GCM_SHA256
xc02b ECDHE-ECDSA-AES128-GCM-SHA256 ECDH 521 AESGCM 128 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
xc023 ECDHE-ECDSA-AES128-SHA256 ECDH 521 AES 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
Running client simulations (HTTP) via sockets
Android 4.2.2 No connection
Android 4.4.2 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 521 bit ECDH (P-521)
Android 5.0.0 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 521 bit ECDH (P-521)
Android 6.0 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Android 7.0 TLSv1.2 ECDHE-ECDSA-CHACHA20-POLY1305, 253 bit ECDH (X25519)
Chrome 65 Win 7 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
Chrome 70 Win 10 TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
Firefox 59 Win 7 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
Firefox 62 Win 7 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
IE 6 XP No connection
IE 7 Vista No connection
IE 8 Win 7 No connection
IE 8 XP No connection
IE 11 Win 7 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 256 bit ECDH (P-256)
IE 11 Win 8.1 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 256 bit ECDH (P-256)
IE 11 Win Phone 8.1 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
IE 11 Win 10 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 256 bit ECDH (P-256)
Edge 13 Win 10 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 256 bit ECDH (P-256)
Edge 13 Win Phone 10 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 256 bit ECDH (P-256)
Edge 15 Win 10 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 253 bit ECDH (X25519)
Opera 17 Win 7 TLSv1.2 ECDHE-ECDSA-AES128-SHA256, 256 bit ECDH (P-256)
Safari 9 iOS 9 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 256 bit ECDH (P-256)
Safari 9 OS X 10.11 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 256 bit ECDH (P-256)
Safari 10 OS X 10.12 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 256 bit ECDH (P-256)
Apple ATS 9 iOS 9 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 256 bit ECDH (P-256)
Tor 17.0.9 Win 7 No connection
Java 6u45 No connection
Java 7u25 No connection
Java 8u161 TLSv1.2 ECDHE-ECDSA-AES256-SHA384, 256 bit ECDH (P-256)
Java 9.0.4 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 256 bit ECDH (P-256)
OpenSSL 1.0.1l TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 521 bit ECDH (P-521)
OpenSSL 1.0.2e TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 256 bit ECDH (P-256)
Done 2019-02-08 11:06:45 [ 118s] -->> 10.243.49.64:18080 (10.243.49.64) <<--
Change-Id: I92a77807848354379ea2cbaa31767eeceadae295
Signed-off-by: Ed Tanous <ed.tanous@intel.com>
|
|
This reverts commit 54fd221a9139f46c7c95b4a22cc09e6e7ce4cbbc.
Reason for revert: This breaks compatibility with python automation running on ubuntu 16.04, and regresses our ability to run the test harness. Suspect we need to run compat C by default, but lets revert for now to stabilize.
Change-Id: I4a01450836d917cd9558bc826c1877e629280850
|
|
Previously, bmcweb was utilitizing the "mozilla compatibility" cipher
suites. This is overly lenient on broken ciphers and can cause some
issues with security reviews. In researching this, it looks like we
never actually documented that we follow Mozilla ciphers, aside from the
statement "The OpenBMC webserver shall follow the latest OWASP recommendations for
authentication, session management, and security." Considering that
we're moving _to_ OWASP recommendations, this commit is simply making us
follow the advice we already document, although this commit also updates
the documentation to be more clear.
Tested By:
Loaded on a BMC, opened web page in browser, and observed phosphor-webui
loaded correctly.
Change-Id: I912b35d378ce955c1472b2d54f1a365f6efea160
Signed-off-by: Ed Tanous <ed.tanous@intel.com>
|
|
In a lot of cases, the header include patterns were really bad. For
example, pulling in all of boost asio via boost/asio.hpp, rather than
pulling in the lesser equivalents. This should reduce the build times,
although I have no data on that at the moment.
Tested By:
Code still compiles
Change-Id: I0f4656d35cf6d7722d1b515baaccbfc27cf98961
Signed-off-by: Ed Tanous <ed.tanous@intel.com>
|
|
This commit moves the codebase to the lastest clang-format file from
upstream, as well as clang-format-6.0.
Change-Id: Ice8313468097c0c42317fbb9e10ddf036e8cff4c
Signed-off-by: Ed Tanous <ed.tanous@intel.com>
|
|
This patchset moves bmcweb over to the upstream style naming
conventions for variables, classes, and functions, as well as imposes
the latest clang-format file.
This changeset was mostly built automatically by the included
.clang-tidy file, which has the ability to autoformat and auto rename
variables. At some point in the future I would like to see this in
greater use, but for now, we will impose it on bmcweb, and see how it
goes.
Tested: Code still compiles, and appears to run, although other issues
are possible and likely.
Change-Id: If422a2e36df924e897736b3feffa89f411d9dac1
Signed-off-by: Ed Tanous <ed.tanous@intel.com>
|
|
Problems were found in compatibility with older versions of curl and
wget. At some point, this option needs to be made runtime configurable.
Tested by:
Using curl to log into rest API.
Logging into webui.
Change-Id: I29620cbae73735e846efc1cc22df6899dbe595df
Signed-off-by: Ed Tanous <ed.tanous@intel.com>
|
|
Change-Id: I86146edde21bac89e6cc30afdd79690e2b0adadd
|
|
Do not merge yet
Change-Id: I38c56844c1b0e3e8e5493c2705e62e6db7ee2102
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
