http://bugzilla.opensuse.org/show_bug.cgi?id=1127591 Bug ID: 1127591 Summary: zypper option "ssl_capath" not working for mirror URLs from metalink file Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: x86-64 OS: SUSE Other Status: NEW Severity: Normal Priority: P5 - None Component: libzypp Assignee: zypp-maintainers@forge.provo.novell.com Reporter: cunix@bitmessage.ch QA Contact: qa-bugs@suse.de CC: security-team@suse.de Found By: --- Blocker: --- Using zypper (version: 1.14.12) for the update repository of openSUSE Leap 15.0 with the option baseurl=https://download.opensuse.org/update/leap/15.0/oss/?proxy=127.0.0.1&proxyport=3333&auth=digest&proxyuser=username&proxypass=password&ssl_capath=/path/to/directory/with/c_rehash/rootCAs does not use the here configured trusted root certificates for mirror URLs, probably retrieved from a metalink file. The configured path is used for the initial connection to download.opensuse.org but following requests to mirrors seem to fallback to the system trusted certs from /etc/ssl/certs. If the mirrors' root CA is trusted in "ssl_capath=/path/to/directory/with/c_rehash/rootCAs" but not in /etc/ssl/certs, zypper,libzypp, multi-curl or something else aborts the TLS-Handshake with failure "Unknown CA (48)" and falls futher back to http (without transport layer encryption). Question for cc'ed security-team to answer: If using clear text is considered a security flaw where zypper is configured to use (https-)encryption, this might have security implications. Some Scenarios: Assume download.opensuse.org is signed by CA A and the mirror by CA B Assume further, ssl_capath=/path/to/directory/with/c_rehash/rootCAs is directory C and directory D is /etc/ssl/certs 1. If C includes A and B and in D at least B is not available, I would expect zypper to encrypt both connection, but the request to the mirror is not. 2. If A is not in C, no data (meta link file) is retrieved and therefore no mirror is connected - Good! No fallback of looking for A in D occurs. 3. If A is in C and B in D, both connections are encrypted. 4. If A is in C and B not in C and not in D, the mirror is contacted unencrypted - here I'm unsure if using plain text in this scenario is correct or if it should fail. So, in my opinion, 1. is the bug, 3. a workaround and 4. perhaps needs a zypper option to configure, if clear text fallback should be allowed. Another question is, if /etc/ssl/certs should actually be consulted when the option "ssl_capath" is used and pointing to a different directory. https://bugzilla.opensuse.org/show_bug.cgi?id=933839 might be related (similar setup). Problem and solution might be similar, too. By the way, is there a debugging option to dump the traffic from inside the encrypted connection? Especially being able to read the metalink file with the listed mirrors is of interest. -- You are receiving this mail because: You are on the CC list for the bug.