I have some private repositories that kiosks connect to over SSL. I don’t want to use basic auth as it’s not very secure for a variety of reasons (for example, the password is sent every connection, giving a large attack surface).
On distros with yum I’ve been able to use client certificate authentication by simply setting sslclientkey=<keyfile> and sslclientcert=<certfile> in the .repo files. However, I can’t find anything about client certificates in the zypper documentation. Are client certificates not supported in zypper like they are in yum? Any suggested workarounds, other than falling back to basic auth or going over SSH instead of HTTPS?
This might go some way to showing how trusted root certificates can be used with openSUSE
https://blog.hqcodeshop.fi/archives/157-Installing-own-CA-root-certificate-into-openSUSE.html
That’s about all I can offer.
On 2015-05-14 08:56, Prune wrote:
> On distros with yum I’ve been able to use client certificate
> authentication by simply setting sslclientkey=<keyfile> and
> sslclientcert=<certfile> in the .repo files. However, I can’t find
> anything about client certificates in the zypper documentation. Are
> client certificates not supported in zypper like they are in yum?
Zypper uses GPG certification.
I don’t know if some mirrors do setup https, but the overall system
doesn’t rely in it, as mirrors are chosen almost randomly and most use
plain http or ftp.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
Based purely on observation and not in any way bolstered by closely inspecting the sessions…
SSL is used only to encrypt the session and is not relied upon for authentication (although I would think that openssl patches within last couple years likely enforce authenticating the server).
When you originally configure a repository, openSUSE (and zypper or yast or whatever) will prompt for the GPG’s public certificate if it’s not already in the local certificate store. When automating setting up a repository, this can be overcome by automatically agreeing or not verifying. You can inspect the various repository security options with the following command (ar is the switch that adds a repo)
zypper ar --help
HTH,
TSU
It does, but GPG provides verification of the downloaded code, not authentication of the client to the repository.
In any case, I have filed a bug report: 932393 – Zypper doesn't support client certificate authentication
On 2015-05-27 05:26, Prune wrote:
>
> robin_listas;2709976 Wrote:
>>
>> Zypper uses GPG certification.
>>
> It does, but GPG provides verification of the downloaded code, not
> authentication of the client to the repository.
Why do you need to authenticate the client to the server (the repo
server)? I don’t see the need at all.
> In any case, I have filed a bug report:
> https://bugzilla.opensuse.org/show_bug.cgi?id=932393
You say there:
|> Private repositories have important use cases, and that makes
authentication of the package manager to the repository a concern.
|> Unfortunately, zypper only seems to support basic authentication.
However, basic authentication even over TLS doesn’t provide good security.
|> The large attack window caused by sending the password with every
request is just one of numerous issues ([1], [2], and many others).
Why do you need to send any password at all? I don’t. I don’t think
anybody does, as the openSUSE download site doesn’t request any password
or authentication.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
You aren’t authenticating the client to the server, you’re authenticating (verifying the identity) of the source repository you’re connecting to.
Should be logical, when you download apps to your machine and update/patch your machine, wouldn’t you want some way of knowing that you’re getting that from a real, official source and not someone impersonating? Wouldn’t you want some protection against someone trying to insert malware into your system?
That is why,
As the client you accept the GPG public certificate issued by the repository.
The public certificate is kind of like a password (or secret) which due to how certificates work can be transferred in the open without compromising its functionality. if you want to understand how this works, I recommend you do a search using the keywords “pki public key infrastructure”
TSU
On 2015-05-27 16:16, tsu2 wrote:
> You aren’t authenticating the client to the server, you’re
> authenticating (verifying the identity) of the source repository you’re
> connecting to.
> Should be logical, when you download apps to your machine and
> update/patch your machine, wouldn’t you want some way of knowing that
> you’re getting that from a real, official source and not someone
> impersonating? Wouldn’t you want some protection against someone trying
> to insert malware into your system?
That’s so. The repository itself is identified by a GPG signature. It
doesn’t matter what mirror serves it, official or not, as long as the
GPG checks (and zypper does verify this). And this way mirrors don’t
need to pay for the certificates used on https servers.
Also repos can work via plain FTP.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Why do you need to authenticate to your bank when you want to check your statements online? Because what you get back—the display of your transaction history—is private information!
Note I wrote “private repositories” in the original post. I don’t want public access to packages of internal company software intended solely for distribution to the trusted client machines (kiosks).
Here’s another way to look at it: why does zypper support basic authentication (through the username:password@url syntax) if you don’t need authentication? And why does yum support both that, as well as client certificate authentication? Because lack of authentication restricts use cases to only public repositories.
On 2015-05-27 21:36, Prune wrote:
>
> robin_listas;2712281 Wrote:
>>
>> Why do you need to authenticate the client to the server (the repo
>> server)? I don’t see the need at all.
> Note I wrote “private repositories” in the original post. I don’t want
> public access to packages of internal company software intended solely
> for distribution to the trusted client machines (kiosks).
You did not say this before. It changes the issue completely.
I suggest you explain this in the Bugzilla, or it will go ignored.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
I don’t follow. As I reiterated, it’s right in the first post: “private repositories”. I also made sure it was in the Bugzilla report.
On 2015-05-28 00:06, Prune wrote:
>
> robin_listas;2712380 Wrote:
>>
>>> Note I wrote “private repositories” in the original post.
>> …
>> You did not say this before. It changes the issue completely.
> I don’t follow. As I reiterated, it’s right in the first post: “private
> repositories”. I also made sure it was in the Bugzilla report.
Yes, but not clear enough. I did not understand it, I thought you were
referring to the home repositories in the OBS. I will not be the only
one that did not understood it, so if you want a reaction in Bugzilla,
better make that point clear, because it makes a huge difference
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
I haven’t read the bug report, but it was clear enough to me in the opening post. What is possible is another issue entirely.
First,
IMO the original post is unintentionally unclear because the User may not realize that the conventional definition of a “private repo” around here is simply that the repo is not a community repo. This very broad definition of a private repo means that the repo might be located anywhere (including OBS, but could also be for instance a local instance or a network location in the User network). A private repo does not necessarily mean it’s to be used only for private use and implements security restricting access, many “private repos” on OBS for instance are simply personal creations but open for anyone to access.
That said, it’s clear now that the User wishes to serve files only to authenticated clients.
From the zypper MAN file (Only relevant parts)
NOTE: The quote is imperfect, have inserted some spaces to avoid this Forum software converting into emoticons. Use only code from the original MAN
Supported URI formats:
scheme: //[user[: password]@]host: port]] /path ?query] #fragment]
Special characters occurring in URI components (like a @ in a password) must be %-encoded (%40).
FTP/HTTP/HTTPS directory tree The ftp URL scheme supports absolute and relative paths to the default ftp server directory
(RFC1738, Section 3.2.2). To use an absolute path, you have to prepend the path with an additional
slash, what results in a /%2f combination (second / encoded to %2f) at the begin of the URL path.
This is important, especially in user authenticated ftp, where the users home is usually the
default directory of the server (except when the server chroots into the users home directory).
Explicit proxy settings may be passed via optional parameters proxy, proxyport, proxyuser and
proxypass.
HTTP authentication methods to use can be defined as comma separated list via optional parameter
auth. Valid methods are e.g. basic, digest, ntlm, negotiate. Note, that this list depends on the
list of methods supported by the curl library.
ftp://user: pass@server/path/to/media/dir
ftp://user: pass@server/%2fhome/user/path/to/media/dir
http://user: pass@server/path
https://user: pass@server/path?proxy=foo&proxyuser=me&proxypass=pw
From the above,
- It’s clear that native zypper client authentication is based on a username: password schema. Examples of ftp and http URI are given.
- Basic authentication is not the only authentication supported, although I’m a bit surprised at the options "digest and “ntlm” which are MS Windows technologies (I’d have to look more closely to verify a Linux authentication subsystem for those common authentication methods is provided). Of course “negotiate” is simply the ability to negotiate a common authentication method both Server and Client support. In any case, for anyone who supports web servers, the provided choices are fairly standard, common and well known so it’s probably a good guess that zypper is simply implementing an embedded web server (likely stub).- The one thing I’m a bit uneasy about is that if zypper is using common authetication protocols, then it would be strongly advisable to doublecheck the strength and implementation of the subsystem but I don’t see any documentation how to do that (maybe it would require looking up the zypper source code).
- The following OP comment should be understood properly since IMO it’s an incomplete evaluation
The large attack window caused by sending the password with every request is just one of numerous issues ([1], [2], and many others).
First, do you really believe that executing client session authentication with each request is bad? In general, ntlm.v2 and digest are considered sufficiently strong for common every day use across the Internet on many, many websites. IIRC Basic is weaker, so should not be used except when you must, but even then you should be able to weigh your options appropriately… ie how many times are you executing a new session within a particular length of time?
Note also that the documentation describes an alternative for more security-conscious deployments… Deploying a proxy server in front of your zypper repo.
By deploying a proxy FW, you take complete control over your network security… You can implement your own rules and methods (still mostly HTTP/FTP based). You can implement a 4096-bit server certificate if you want. You can implement any kind of client authentication you want, including client certs.
HTH,
TSU
I already mentioned this in the thread.
That’s not what I implied. The issue is what “executing client session authentication” entails. With basic authentication, the username and password are sent in full every request (the password isn’t even hashed, just base64 encoded). In general you have multiple requests per TLS session, and, of course, there isn’t a different IV/nonce used for each request; though an appropriate cipher block mode guards against the highly repeated plaintext being a big weakening, it does not do so perfectly. Client certificate authentication, on the other hand, never transmits private data for authentication in the first place; the CertificateVerify message is based on client private key-signed hashes of the preceding handshake messages that include inconstant components such as the session ID.
That is a workaround, albeit one that adds complexity and thus reduces maintainability. My argument for the appropriateness of inclusion of client certificates is based on the fact that it is quite standard, easy to deploy by users, and is implemented in all sorts of software that supports TLS, from pretty much all browsers, to all major web servers, to even other package managers.
IMHO, this is equivalent to the “just use VPN” approach, which is suboptimal for various reasons, not least of all that even IPSec VPNs don’t have the level of standardization and wide support that TLS does.
On 2015-05-31 00:06, tsu2 wrote:
> From the zypper MAN file (Only relevant parts)
> NOTE:__The_quote_is_imperfect,_have_inserted_some_spaces_to_avoid_this_Forum_software_converting_into_emoticons.Use_only_code_from_the_original_MAN
>> >
>> > Supported URI formats:
That’s what code tags are used for
In a village of La Mancha, the name of which I have no desire to call to mind, there lived not long since one of those gentlemen that keep a lance in the lance-rack, an old buckler, a lean hack, and a greyhound for coursing. An olla of rather more beef than mutton, a salad on most nights, scraps on Saturdays, lentils on Fridays, and a pigeon or so extra on Sundays, made away with three-quarters of his income. The rest of it went in a doublet of fine cloth and velvet breeches and shoes to match for holidays, while on week-days he made a brave figure in his best homespun. He had in his house a housekeeper past forty, a niece under twenty, and a lad for the field and market-place, who used to saddle the hack as well as handle the bill-hook. The age of this gentleman of ours was bordering on fifty; he was of a hardy habit, spare, gaunt-featured, a very early riser and a great sportsman. They will have it his surname was Quixada or Quesada (for here there is some difference of opinion amo
ng the authors who write on the subject), although from reasonable conjectures it seems plain that he was called Quexana. This, however, is of but little importance to our tale; it will be enough not to stray a hair's breadth from the truth in the telling of it.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
I hope the choice of quote is incidental and not to imply that, in my concern with digital adversaries, I am tilting at windmills.
I’m sure that Carlos was directing his comment to me…
For some reason, at least as I was building my post when I changed the block code from QUOTE to CODE, the emoticons still showed up.
Maybe might have been different if I built the post using CODE blocks from the beginning…
TSU
In general, the high number of times you’d see authentication is because that’s the nature of HTTP sessions no matter what authentication method is used. The way to avoid is to use different security like a non-SSL VPN. But, then the trade-off is that non-SSL VPNs will require a higher memory overhead.
As I described earlier, it looks like zypper is implementing web type security so if basic authentication bothers you, then according to the docs you can implement ntlm or digest instead… and at least when I support a website I do exactly that when the website is backed by MS security. Implementing ntlm and digest without MS security is new to me, I’d have to research further if that can be done today without MS security. Also, AFAIK your “weakness” description only applies to an older or more common implementation. IIRC a couple years ago I read that a more advanced method of managing “secrets” was already being implemented although would require both ends to support. Sorry, I don’t have something more specific off the top of my head and it’s not like I’m checking how TLS/SSL is evolving constantly.
Whether you use certificates or not is not an indicator of the type of session and how often authentication is executed. Certs are used by a number of different technologies to secure by encryption and identify end points. In general, for as long as typical content is transferred in a single session, I think the general opinion is that current implementations are sufficient.
As for implementing a Proxy server, IMO it’s only a little more than a pita and I don’t think it’s just my opinion. A proxy server can perform impersonation so that the connection between it and the real resource it’s protecting can be a simple, even insecure (in many cases) configuration. Everything related to security is setup in the proxy server, besides choice of connectivity, it will also either use local security or pass authentication to practically anything you wish.
TSU
On Sun 31 May 2015 12:46:02 AM CDT, tsu2 wrote:
Prune;2712886 Wrote:
> I hope the choice of quote is incidental and not to imply that, in my
> concern with digital adversaries, I am tilting at windmills.
I’m sure that Carlos was directing his comment to me…
For some reason, at least as I was building my post when I changed the
block code from QUOTE to CODE, the emoticons still showed up.
Maybe might have been different if I built the post using CODE blocks
from the beginning…
TSU
Hi
You can select the ‘advanced’ editor options, there is a checkbox to
select to disable the emoticons in your post as well.
–
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
SUSE Linux Enterprise Desktop 12 GNOME 3.10.1 Kernel 3.12.39-47-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!