Somewhat conflicting configuration and strange behaviour (was: SELinux prevents running squid 3.3.11 on CentOS 6.5)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Somewhat conflicting configuration and strange behaviour (was: SELinux prevents running squid 3.3.11 on CentOS 6.5)

Walter H.
Hello Eliezer Croitoru,

this is also to the OpenSSL mailing list, because can someone verify that
the CA certificate and the SSL certificate fit together - the last
section of this mail.
(of course I can do this by myself, but here I want to opinion of a 3rd
party)

I have the solution that worked at my system, to run SELinux with enforcing
first you need to install a special package

yum install policycoreutils-python

then do this to filter the audit log:
(at my system only squid entries are questionable,
in case there are more programmes that can run only
with SELinux turned off or setting to permissive,
you must sort out these entries of course)

cat /var/log/audit/audit.log | grep -v "success" > avc

the next step to generate the policy file

audit2allow -M avc < avc

this generates avc.pp. with this do:

semodule -i avc.pp

that was it;

(I'm not an expert I got just hints from my workmate)
--
I found out something strange ...

when using the .repo files here ...
http://wiki.squid-cache.org/SquidFaq/BinaryPackages#CentOS

the package
http://software.opensuse.org/download.html?project=home%3Aairties%3Aserver&package=squid3
gives this error, when installing with   'yum install squid3'
Error: Package: squid3-3.3.8-6.1.x86_64 (home_airties_server)
            Requires: perl(Authen::Smb)

the other packages require the epel repo to be installed before ...
but how can I install squid 3.3?
there is only the question if its ok to install 7:squid-3.4.0-3-1...
I tried this
yum install
http://www1.ngtech.co.il/rpm/centos/6/x86_64/squid-3.3.11-1.el6.x86_64.rpm
and it worked ..., with SELinux=permissive and also with the above with
SELinux=enforcing

the only question: how to use a parent proxy with both of the following ...

cache_peer #ip# 3128 0 proxy-only
never_direct allow all

and

ssl_bump server-first all
always_direct allow all

..., conflicting a little bit ...?

with other words, how to use a parent proxy while doing ssl-bump?
(the firewall blocks direkt access of this proxy, only the parent proxy
has access to the internet)
--
my squid.conf has the default entries plus (here without parent proxy)

<squid.conf>
ssl_bump server-first all
# these will be adapted to my needs, here for testing only
sslproxy_cert_error allow all
sslproxy_flags DONT_VERIFY_PEER

sslcrtd_program /usr/lib64/squid/ssl_crtd -s /var/lib/squid/ssl_db -M 4MB
sslcrtd_children 5

always_direct allow all

http_port 3128 ssl-bump generate-host-certificates=on
dynamic_cert_mem_cache_size=4MB cert=/etc/squid/cert/squid.pem
options=NO_SSLv2
</squid.conf>

I'm using no caching directory, this should be the work of the parent
proxy ..., the squid.pem is shown below:

the purpose of this server is just doing smart filtering on HTTPS;
--
can please someone tell me why I get in FF (in an old 3.6 and in an
relatively actual one 24.2esr)

This Connection is Untrusted

www.google.nl uses an invalid security certificate.
The certificate is not trusted because it was issued by an invalid CA
certificate.
(Error code: sec_error_inadequate_key_usage)

only for urls that are shown in the Subject alternative name of the
attached SSL certificate
and result in this certificate ...?

and this is only with FF, not with IE and not with Google Chrome itself ...
all other SSL sites work well ...
--
when I talk about I server, it is of course just a virtual machine on my
computer, of these I have a few:
- mail server
- dns server
- proxy server (with caching and smart filtering for non-https)
- ...

Thanks,
Walter

--[ audit.log extract ]--

type=AVC msg=audit(1386721165.548:990): avc:  denied  { write } for  
pid=6689 co
mm="ssl_crtd" name="size" dev=sda3 ino=395149
scontext=unconfined_u:system_r:squ
id_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file
type=AVC msg=audit(1386721165.548:991): avc:  denied  { write } for  
pid=6689 co
mm="ssl_crtd" name="certs" dev=sda3 ino=395148
scontext=unconfined_u:system_r:sq
uid_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=dir
type=AVC msg=audit(1386721165.548:991): avc:  denied  { remove_name }
for  pid=6
689 comm="ssl_crtd" name="79B5336452F44EE14155FEF0042BCA6C6A1AFC12.pem"
dev=sda3
  ino=395199 scontext=unconfined_u:system_r:squid_t:s0
tcontext=unconfined_u:obje
ct_r:var_lib_t:s0 tclass=dir
type=AVC msg=audit(1386721165.548:991): avc:  denied  { unlink } for  
pid=6689 c
omm="ssl_crtd" name="79B5336452F44EE14155FEF0042BCA6C6A1AFC12.pem"
dev=sda3 ino=
395199 scontext=unconfined_u:system_r:squid_t:s0
tcontext=unconfined_u:object_r:
var_lib_t:s0 tclass=file
type=AVC msg=audit(1386721165.550:992): avc:  denied  { add_name } for  
pid=6689
  comm="ssl_crtd" name="58481355CE5F10BBF9DF4CD4B99692BC308E4D42.pem"
scontext=un
confined_u:system_r:squid_t:s0
tcontext=unconfined_u:object_r:var_lib_t:s0 tclas
s=dir
type=AVC msg=audit(1386721165.550:992): avc:  denied  { create } for  
pid=6689 c
omm="ssl_crtd" name="58481355CE5F10BBF9DF4CD4B99692BC308E4D42.pem"
scontext=unco
nfined_u:system_r:squid_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0
tclass=
file

--[ squid.pem ]--

the private key here is no problem, because its only testing purpose;
the final working squid server gets other certificates ...

-----BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQD1Gf2qk287rvKpwEhyZtyiycvl6C9ZsvLHMKygimTqzoiGrIO4
tbw1bqAZcCju1P0HAXXjFmdVW8WPs6rg2uXtsBEiO9/1gQ6ji6/Kl8yEhyRVXRcH
VMuzx9dSAE4IJzaXNgSqqmHNoacxHZICV7GPaxBqVvflGyJqcc0KDD8MQwIDAQAB
AoGAGExQUnW1RERuuBdg1z6NRvIcbZlcAFd2K/sOUggGQyTgcgFuOYSCuQVTh9IP
rMWeo/AoILAa5GJprnpQSWRKANmUw43Vqj3EzZJMglRhUFUZnNYaC1jWGa3C9os5
n8TAqqnYZtcHdiD/wykI33aK7kOfccxMmlUXyJVqbkEsucECQQD+MrytFio3CfZ9
wZ9Oli3wWujPa8PfSZDnA4EYV0HiWAcYzkaYhX0GtGcjrpB/fHHF/jzQpF+p3dcr
uYHNTAejAkEA9ta/SzQtvVk4k2JsB3aJZv5OGzVkXXR7ijvyE2srrU8ez5Yc2hgA
/lOYale9/mmluGPNyTdm9Oh220E2ij+y4QJBAJ/mOItEew+eI8CdcGGV1JXyCaqY
ZmDpvM2khatTEC2aI/S1pPDCX5A9IPfwEhMvq73ZHFY+X7LRyk1F5uHGJrMCQGSg
hRmGawMfBUZoQDwGodsf3v2OlZzXqKlg6L3r2cFsWNYtjxOF55nGwILRxD2cGhgC
b9kQweMjhZi6jB5t+2ECQQCDzLY91w+JgOS2HasRm2DUHo67shRfwmWfFdl1vAs5
Q0ysK1EsBuIQxRLVyBCBqEWZDGTFJMlq8ShfRskD28jz
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIICZzCCAdCgAwIBAgIBETANBgkqhkiG9w0BAQUFADBHMQswCQYDVQQGEwItLTEQ
MA4GA1UEChMHU29tZU9yZzEUMBIGA1UECxMLU29tZU9yZ1VuaXQxEDAOBgNVBAMT
B1Jvb3QgQ0EwHhcNNzAwMTAxMDAwMDAwWhcNMzQxMjMxMjM1OTU5WjBHMQswCQYD
VQQGEwItLTEQMA4GA1UEChMHU29tZU9yZzEUMBIGA1UECxMLU29tZU9yZ1VuaXQx
EDAOBgNVBAMTB1Jvb3QgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPUZ
/aqTbzuu8qnASHJm3KLJy+XoL1my8scwrKCKZOrOiIasg7i1vDVuoBlwKO7U/QcB
deMWZ1VbxY+zquDa5e2wESI73/WBDqOLr8qXzISHJFVdFwdUy7PH11IATggnNpc2
BKqqYc2hpzEdkgJXsY9rEGpW9+UbImpxzQoMPwxDAgMBAAGjYzBhMA8GA1UdEwEB
/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTea3zoMP5FWNxG50df
7Hbnid5sBjAfBgNVHSMEGDAWgBTea3zoMP5FWNxG50df7Hbnid5sBjANBgkqhkiG
9w0BAQUFAAOBgQC2XuM7jij2ujgNDipMLcUE/Tlpg8IeKZThl2cLWUT0RtHW2CHK
hIKOlCMP2xMB3EMbTGSc7p5DMA5P4CcF6PsTfKxl7pAn6uDgWHk3e52imgHs7Q1G
9buVgx3NHrKrbtEGE9vt1QAh8TnLo6LEPAkHCECCeS5gMG4IZpATNReCxQ==
-----END CERTIFICATE-----

--[ SSL certificate ]--

Certificate:
...
         X509v3 extensions:
             X509v3 Subject Alternative Name:
                 DNS:*.google.com, DNS:*.android.com,
DNS:*.appengine.google.com,
  DNS:*.cloud.google.com, DNS:*.google-analytics.com, DNS:*.google.ca,
DNS:*.goog
le.cl, DNS:*.google.co.in, DNS:*.google.co.jp, DNS:*.google.co.uk,
DNS:*.google.
com.ar, DNS:*.google.com.au, DNS:*.google.com.br, DNS:*.google.com.co,
DNS:*.goo
gle.com.mx, DNS:*.google.com.tr, DNS:*.google.com.vn, DNS:*.google.de,
DNS:*.goo
gle.es, DNS:*.google.fr, DNS:*.google.hu, DNS:*.google.it,
DNS:*.google.nl, DNS:
*.google.pl, DNS:*.google.pt, DNS:*.googleapis.cn,
DNS:*.googlecommerce.com, DNS
:*.gstatic.com, DNS:*.urchin.com, DNS:*.url.google.com,
DNS:*.youtube-nocookie.c
om, DNS:*.youtube.com, DNS:*.youtubeeducation.com, DNS:*.ytimg.com,
DNS:android.
com, DNS:g.co, DNS:goo.gl, DNS:google-analytics.com, DNS:google.com,
DNS:googlec
ommerce.com, DNS:urchin.com, DNS:youtu.be, DNS:youtube.com,
DNS:youtubeeducation
.com
...

-----BEGIN CERTIFICATE-----
MIIFPTCCBKagAwIBAgIUPXX9MOspr8vFn1yK/75ufujyNyMwDQYJKoZIhvcNAQEF
BQAwRzELMAkGA1UEBhMCLS0xEDAOBgNVBAoTB1NvbWVPcmcxFDASBgNVBAsTC1Nv
bWVPcmdVbml0MRAwDgYDVQQDEwdSb290IENBMB4XDTEzMTEyMDE1MTMzNloXDTE0
MDMyMDAwMDAwMFowZjELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWEx
FjAUBgNVBAcMDU1vdW50YWluIFZpZXcxEzARBgNVBAoMCkdvb2dsZSBJbmMxFTAT
BgNVBAMMDCouZ29vZ2xlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
9Rn9qpNvO67yqcBIcmbcosnL5egvWbLyxzCsoIpk6s6IhqyDuLW8NW6gGXAo7tT9
BwF14xZnVVvFj7Oq4Nrl7bARIjvf9YEOo4uvypfMhIckVV0XB1TLs8fXUgBOCCc2
lzYEqqphzaGnMR2SAlexj2sQalb35RsianHNCgw/DEMCAwEAAaOCAwUwggMBMIIC
wwYDVR0RBIICujCCAraCDCouZ29vZ2xlLmNvbYINKi5hbmRyb2lkLmNvbYIWKi5h
cHBlbmdpbmUuZ29vZ2xlLmNvbYISKi5jbG91ZC5nb29nbGUuY29tghYqLmdvb2ds
ZS1hbmFseXRpY3MuY29tggsqLmdvb2dsZS5jYYILKi5nb29nbGUuY2yCDiouZ29v
Z2xlLmNvLmlugg4qLmdvb2dsZS5jby5qcIIOKi5nb29nbGUuY28udWuCDyouZ29v
Z2xlLmNvbS5hcoIPKi5nb29nbGUuY29tLmF1gg8qLmdvb2dsZS5jb20uYnKCDyou
Z29vZ2xlLmNvbS5jb4IPKi5nb29nbGUuY29tLm14gg8qLmdvb2dsZS5jb20udHKC
DyouZ29vZ2xlLmNvbS52boILKi5nb29nbGUuZGWCCyouZ29vZ2xlLmVzggsqLmdv
b2dsZS5mcoILKi5nb29nbGUuaHWCCyouZ29vZ2xlLml0ggsqLmdvb2dsZS5ubIIL
Ki5nb29nbGUucGyCCyouZ29vZ2xlLnB0gg8qLmdvb2dsZWFwaXMuY26CFCouZ29v
Z2xlY29tbWVyY2UuY29tgg0qLmdzdGF0aWMuY29tggwqLnVyY2hpbi5jb22CECou
dXJsLmdvb2dsZS5jb22CFioueW91dHViZS1ub2Nvb2tpZS5jb22CDSoueW91dHVi
ZS5jb22CFioueW91dHViZWVkdWNhdGlvbi5jb22CCyoueXRpbWcuY29tggthbmRy
b2lkLmNvbYIEZy5jb4IGZ29vLmdsghRnb29nbGUtYW5hbHl0aWNzLmNvbYIKZ29v
Z2xlLmNvbYISZ29vZ2xlY29tbWVyY2UuY29tggp1cmNoaW4uY29tggh5b3V0dS5i
ZYILeW91dHViZS5jb22CFHlvdXR1YmVlZHVjYXRpb24uY29tMAsGA1UdDwQEAwIH
gDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQUFAAOBgQA4xQFls1FpUScdCmifTkWCrjNrgUCbL56im1/9vSqM
P8IplBopOikz3VnxBsyUVaR/yt8zzm158zYdIpA/rOX0WukwO4pAUoi6aw6Q+FoD
ZG+3Qe0b7a22Mqgl45OlfljrAMfouvapjx8OA9COSM/2k2TtRnlEy7D929O2H6J6
CQ==
-----END CERTIFICATE-----




On 09.12.2013 06:30, Eliezer Croitoru wrote:

> Hey Walter,
>
> I do not know yet of a way to get SELinux work with squid nicely.
> I do know it can be done with enough knowledge and couple additions.
>
> If anyone is a SELinux expert or just can find the appropriate way of
> handling squid conflicts with SELinux I would be happy to try to push
> these into the RPMs.
>
> For now the suggestion is to use selinux policy to permissive while on
> most squid systems(dedicated) you wont force selinux but I am still
> not sure why.
>
> Fedora has some docs about it:
> http://docs.fedoraproject.org/en-US/Fedora/13/html/Managing_Confined_Services/chap-Managing_Confined_Services-Squid_Caching_Proxy.html 
>
>
> This setting direction policy will might help something:
>  setsebool -P squid_connect_any 1
>
> And at redhat couple notes:
> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Confined_Services/chap-Managing_Confined_Services-Squid_Caching_Proxy.html 
>
>
>
> Can you share the errors you see in logs? either squid logs or
> messages log?
>
> Are you using a cache_dir ?
>
> There is also a demonstration on how to create a selinux module\policy
> fro qlproxy:
> http://sichent.wordpress.com/2011/05/10/build-selinux-policy-for-your-next-daemon-part-1/ 
>
>
> I hope it helps.
>
> Eliezer
>
> On 08/12/13 22:34, Walter H. wrote:
>> Hello,
>>
>> I have the ident problem as here:
>> http://comments.gmane.org/gmane.comp.web.squid.general/99601
>>
>> SELinux=enforcing prevents running squid ...
>>
>> my system: a CentOS 6.5, squid-3.3.11
>>
>> ./configure --enable-ssl
>>              --enable-ssl-crtd
>>              --disable-htcp
>>              --disable-eui
>>              --disable-snmp
>>              --enable-useragent-log
>>              --enable-referer-log
>>              --enable-cachemgr-hostname=localhost
>>                --prefix=/usr
>>                --includedir=/usr/include
>>                --datadir=/usr/share
>>                --bindir=/usr/sbin
>>                --libexecdir=/usr/lib/squid
>>                --localstatedir=/var
>>                --sysconfdir=/etc/squid
>>              --with-dl
>>              --with-openssl
>>              --with-pthreads
>>              --with-logdir=/var/log/squid
>>              --with-default-user=squid
>>
>> can someone give me a hint, what to do?
>>
>> by the way, the binary packages from here:
>> http://wiki.squid-cache.org/SquidFaq/BinaryPackages#CentOS
>> have the same problem ...
>>
>> Thanks,
>> Walter
>>
>>


smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Somewhat conflicting configuration and strange behaviour

Erwann ABALEA
Bonjour,

The certificate specifies "digitalSignature" as its sole key usage.
That means the certified key can only be used to sign data, and not
perform any decrypt operation.

If your server+client are negotiating a (EC)DHE-RSA-* ciphersuite,
that's OK because the server's RSA private key will then be used to sign
the (EC)DHE parameters and ephemeral public key, and the key exchange
mechanism will be based on (EC)DHE.

But if the negotiated ciphersuite is AES-* or DES-* or RC4-* or anything
similar using RSA as the key exchange mechanism, it won't work because
the private key will then be used to decrypt the premaster secret.

Only NSS checks this, so Firefox under any OS, and Chrome under Linux.

If you want to get rid of this message, choose either one of:
  - create a new certificate for your server with
keyUsage=digitalSignature+keyEncipherment
  - setup your server to only allow (EC)DHE key exchange mechanisms, by
tweaking its acceptable ciphersuites

--
Erwann ABALEA

Le 11/12/2013 20:29, Walter H. a écrit :
[...]
> can please someone tell me why I get in FF (in an old 3.6 and in an
> relatively actual one 24.2esr)
>
> This Connection is Untrusted
>
> www.google.nl uses an invalid security certificate.
> The certificate is not trusted because it was issued by an invalid CA
> certificate.
> (Error code: sec_error_inadequate_key_usage)
[...]

> -----BEGIN CERTIFICATE-----
> MIIFPTCCBKagAwIBAgIUPXX9MOspr8vFn1yK/75ufujyNyMwDQYJKoZIhvcNAQEF
> BQAwRzELMAkGA1UEBhMCLS0xEDAOBgNVBAoTB1NvbWVPcmcxFDASBgNVBAsTC1Nv
> bWVPcmdVbml0MRAwDgYDVQQDEwdSb290IENBMB4XDTEzMTEyMDE1MTMzNloXDTE0
> MDMyMDAwMDAwMFowZjELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWEx
> FjAUBgNVBAcMDU1vdW50YWluIFZpZXcxEzARBgNVBAoMCkdvb2dsZSBJbmMxFTAT
> BgNVBAMMDCouZ29vZ2xlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
> 9Rn9qpNvO67yqcBIcmbcosnL5egvWbLyxzCsoIpk6s6IhqyDuLW8NW6gGXAo7tT9
> BwF14xZnVVvFj7Oq4Nrl7bARIjvf9YEOo4uvypfMhIckVV0XB1TLs8fXUgBOCCc2
> lzYEqqphzaGnMR2SAlexj2sQalb35RsianHNCgw/DEMCAwEAAaOCAwUwggMBMIIC
> wwYDVR0RBIICujCCAraCDCouZ29vZ2xlLmNvbYINKi5hbmRyb2lkLmNvbYIWKi5h
> cHBlbmdpbmUuZ29vZ2xlLmNvbYISKi5jbG91ZC5nb29nbGUuY29tghYqLmdvb2ds
> ZS1hbmFseXRpY3MuY29tggsqLmdvb2dsZS5jYYILKi5nb29nbGUuY2yCDiouZ29v
> Z2xlLmNvLmlugg4qLmdvb2dsZS5jby5qcIIOKi5nb29nbGUuY28udWuCDyouZ29v
> Z2xlLmNvbS5hcoIPKi5nb29nbGUuY29tLmF1gg8qLmdvb2dsZS5jb20uYnKCDyou
> Z29vZ2xlLmNvbS5jb4IPKi5nb29nbGUuY29tLm14gg8qLmdvb2dsZS5jb20udHKC
> DyouZ29vZ2xlLmNvbS52boILKi5nb29nbGUuZGWCCyouZ29vZ2xlLmVzggsqLmdv
> b2dsZS5mcoILKi5nb29nbGUuaHWCCyouZ29vZ2xlLml0ggsqLmdvb2dsZS5ubIIL
> Ki5nb29nbGUucGyCCyouZ29vZ2xlLnB0gg8qLmdvb2dsZWFwaXMuY26CFCouZ29v
> Z2xlY29tbWVyY2UuY29tgg0qLmdzdGF0aWMuY29tggwqLnVyY2hpbi5jb22CECou
> dXJsLmdvb2dsZS5jb22CFioueW91dHViZS1ub2Nvb2tpZS5jb22CDSoueW91dHVi
> ZS5jb22CFioueW91dHViZWVkdWNhdGlvbi5jb22CCyoueXRpbWcuY29tggthbmRy
> b2lkLmNvbYIEZy5jb4IGZ29vLmdsghRnb29nbGUtYW5hbHl0aWNzLmNvbYIKZ29v
> Z2xlLmNvbYISZ29vZ2xlY29tbWVyY2UuY29tggp1cmNoaW4uY29tggh5b3V0dS5i
> ZYILeW91dHViZS5jb22CFHlvdXR1YmVlZHVjYXRpb24uY29tMAsGA1UdDwQEAwIH
> gDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAN
> BgkqhkiG9w0BAQUFAAOBgQA4xQFls1FpUScdCmifTkWCrjNrgUCbL56im1/9vSqM
> P8IplBopOikz3VnxBsyUVaR/yt8zzm158zYdIpA/rOX0WukwO4pAUoi6aw6Q+FoD
> ZG+3Qe0b7a22Mqgl45OlfljrAMfouvapjx8OA9COSM/2k2TtRnlEy7D929O2H6J6
> CQ==
> -----END CERTIFICATE-----

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Somewhat conflicting configuration and strange behaviour

Walter H.
Hello,

Thanks for your reply;

Very strange in FF

when I disable the use of the RSA-* Ciphersuites in FF, then I get the
following error

Secure Connection failed
Cannot communicate securely with peer: no common encryption algorithm(s).
(Error code: ssl_error_no_cypher_overlap)

the certificate is mimicked by the origin certificate -
look on the origin certificate of https://www.google.nl

Thanks,
Walter

On 11.12.2013 20:56, Erwann Abalea wrote:

> Bonjour,
>
> The certificate specifies "digitalSignature" as its sole key usage.
> That means the certified key can only be used to sign data, and not
> perform any decrypt operation.
>
> If your server+client are negotiating a (EC)DHE-RSA-* ciphersuite,
> that's OK because the server's RSA private key will then be used to
> sign the (EC)DHE parameters and ephemeral public key, and the key
> exchange mechanism will be based on (EC)DHE.
>
> But if the negotiated ciphersuite is AES-* or DES-* or RC4-* or
> anything similar using RSA as the key exchange mechanism, it won't
> work because the private key will then be used to decrypt the
> premaster secret.
>
> Only NSS checks this, so Firefox under any OS, and Chrome under Linux.
>
> If you want to get rid of this message, choose either one of:
>  - create a new certificate for your server with
> keyUsage=digitalSignature+keyEncipherment
>  - setup your server to only allow (EC)DHE key exchange mechanisms, by
> tweaking its acceptable ciphersuites
>



smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Somewhat conflicting configuration and strange behaviour

Erwann ABALEA
It's not strange.
You removed the RSA-* from client side, the result is that the server
can't match anything in common between what the client proposed and what
the server accepts. The error you get has been sent by the server.

--
Erwann ABALEA

Le 11/12/2013 22:34, Walter H. a écrit :

> Hello,
>
> Thanks for your reply;
>
> Very strange in FF
>
> when I disable the use of the RSA-* Ciphersuites in FF, then I get the
> following error
>
> Secure Connection failed
> Cannot communicate securely with peer: no common encryption algorithm(s).
> (Error code: ssl_error_no_cypher_overlap)
>
> the certificate is mimicked by the origin certificate -
> look on the origin certificate of https://www.google.nl
>
> Thanks,
> Walter
>
> On 11.12.2013 20:56, Erwann Abalea wrote:
>> Bonjour,
>>
>> The certificate specifies "digitalSignature" as its sole key usage.
>> That means the certified key can only be used to sign data, and not
>> perform any decrypt operation.
>>
>> If your server+client are negotiating a (EC)DHE-RSA-* ciphersuite,
>> that's OK because the server's RSA private key will then be used to
>> sign the (EC)DHE parameters and ephemeral public key, and the key
>> exchange mechanism will be based on (EC)DHE.
>>
>> But if the negotiated ciphersuite is AES-* or DES-* or RC4-* or
>> anything similar using RSA as the key exchange mechanism, it won't
>> work because the private key will then be used to decrypt the
>> premaster secret.
>>
>> Only NSS checks this, so Firefox under any OS, and Chrome under Linux.
>>
>> If you want to get rid of this message, choose either one of:
>>  - create a new certificate for your server with
>> keyUsage=digitalSignature+keyEncipherment
>>  - setup your server to only allow (EC)DHE key exchange mechanisms,
>> by tweaking its acceptable ciphersuites
>>
>
>
>

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Somewhat conflicting configuration and strange behaviour

Walter H.
On 12.12.2013 14:16, Erwann Abalea wrote:
> It's not strange.
> You removed the RSA-* from client side, the result is that the server
> can't match anything in common between what the client proposed and
> what the server accepts. The error you get has been sent by the server.
>
The server is capable of ciphers DHE-* and others;
the list is quite longer than the avaiable ciphers of the client ...,
  so I think this is quite strange ...

openssl ciphers -V

shows e.g.  ECDHE-ECDSA-DES-CBC3-SHA
the site https://cc.dcsec.uni-hannover.de/ shows this:
ECDHE-ECDSA-3DES-EDE-SHA

are these the same cipher suites but two confusing names?

Walter




smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Somewhat conflicting configuration and strange behaviour

andrew cooke

it dpends how many characters differ when sorted.

in this case:

ECDHE-ECDSA-DES-CBC3-SHA -> ----3AABCCCCDDDEEEEHHSSS
                                   * *** **
ECDHE-ECDSA-3DES-EDE-SHA -> ----3AACCDDDDEEEEEEHHSSS

you can see (marked by *) that 6 characters don't match.

now 6 is a triangular number, but the length of the entire cipher suite is 24,
which isn't triangule (the closest is 21).

so they're only going to inter-operate on tuesdays.

andrew


On Fri, Dec 13, 2013 at 07:30:02PM +0100, Walter H. wrote:

> On 12.12.2013 14:16, Erwann Abalea wrote:
> >It's not strange.
> >You removed the RSA-* from client side, the result is that the
> >server can't match anything in common between what the client
> >proposed and what the server accepts. The error you get has been
> >sent by the server.
> >
> The server is capable of ciphers DHE-* and others;
> the list is quite longer than the avaiable ciphers of the client ...,
>  so I think this is quite strange ...
>
> openssl ciphers -V
>
> shows e.g.  ECDHE-ECDSA-DES-CBC3-SHA
> the site https://cc.dcsec.uni-hannover.de/ shows this:
> ECDHE-ECDSA-3DES-EDE-SHA
>
> are these the same cipher suites but two confusing names?
>
> Walter
>
>
>


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Somewhat conflicting configuration and strange behaviour

Erwann ABALEA
In reply to this post by Walter H.
Le 13/12/2013 19:30, Walter H. a écrit :
> On 12.12.2013 14:16, Erwann Abalea wrote:
>> It's not strange.
>> You removed the RSA-* from client side, the result is that the server
>> can't match anything in common between what the client proposed and
>> what the server accepts. The error you get has been sent by the server.
>>
> The server is capable of ciphers DHE-* and others;
> the list is quite longer than the avaiable ciphers of the client ...,
>  so I think this is quite strange ...

The ClientHello message will show what ciphersuite is proposed by the
client.
You'll have to match it with what the server is willing to accept.

> openssl ciphers -V
>
> shows e.g.  ECDHE-ECDSA-DES-CBC3-SHA
> the site https://cc.dcsec.uni-hannover.de/ shows this:
> ECDHE-ECDSA-3DES-EDE-SHA
>
> are these the same cipher suites but two confusing names?

I'd say yes, but what is really exchanged is a list of 16 bits numbers,
not names.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Somewhat conflicting configuration and strange behaviour

andrew cooke
In reply to this post by andrew cooke

sorry, that was a bad joke i now regret sending.  andrew

On Fri, Dec 13, 2013 at 04:01:23PM -0300, Andrew Cooke wrote:

>
> it dpends how many characters differ when sorted.
>
> in this case:
>
> ECDHE-ECDSA-DES-CBC3-SHA -> ----3AABCCCCDDDEEEEHHSSS
>                                    * *** **
> ECDHE-ECDSA-3DES-EDE-SHA -> ----3AACCDDDDEEEEEEHHSSS
>
> you can see (marked by *) that 6 characters don't match.
>
> now 6 is a triangular number, but the length of the entire cipher suite is 24,
> which isn't triangule (the closest is 21).
>
> so they're only going to inter-operate on tuesdays.
>
> andrew
>
>
> On Fri, Dec 13, 2013 at 07:30:02PM +0100, Walter H. wrote:
> > On 12.12.2013 14:16, Erwann Abalea wrote:
> > >It's not strange.
> > >You removed the RSA-* from client side, the result is that the
> > >server can't match anything in common between what the client
> > >proposed and what the server accepts. The error you get has been
> > >sent by the server.
> > >
> > The server is capable of ciphers DHE-* and others;
> > the list is quite longer than the avaiable ciphers of the client ...,
> >  so I think this is quite strange ...
> >
> > openssl ciphers -V
> >
> > shows e.g.  ECDHE-ECDSA-DES-CBC3-SHA
> > the site https://cc.dcsec.uni-hannover.de/ shows this:
> > ECDHE-ECDSA-3DES-EDE-SHA
> >
> > are these the same cipher suites but two confusing names?
> >
> > Walter
> >
> >
> >
>
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Somewhat conflicting configuration and strange behaviour

Erwann ABALEA
Don't regret it, it wasn't that bad ;)

--
Erwann ABALEA

Le 13/12/2013 20:39, andrew cooke a écrit :

> sorry, that was a bad joke i now regret sending.  andrew
>
> On Fri, Dec 13, 2013 at 04:01:23PM -0300, Andrew Cooke wrote:
>> it dpends how many characters differ when sorted.
>>
>> in this case:
>>
>> ECDHE-ECDSA-DES-CBC3-SHA -> ----3AABCCCCDDDEEEEHHSSS
>>                                     * *** **
>> ECDHE-ECDSA-3DES-EDE-SHA -> ----3AACCDDDDEEEEEEHHSSS
>>
>> you can see (marked by *) that 6 characters don't match.
>>
>> now 6 is a triangular number, but the length of the entire cipher suite is 24,
>> which isn't triangule (the closest is 21).
>>
>> so they're only going to inter-operate on tuesdays.
>>
>> andrew
>>
>>
>> On Fri, Dec 13, 2013 at 07:30:02PM +0100, Walter H. wrote:
>>> On 12.12.2013 14:16, Erwann Abalea wrote:
>>>> It's not strange.
>>>> You removed the RSA-* from client side, the result is that the
>>>> server can't match anything in common between what the client
>>>> proposed and what the server accepts. The error you get has been
>>>> sent by the server.
>>>>
>>> The server is capable of ciphers DHE-* and others;
>>> the list is quite longer than the avaiable ciphers of the client ...,
>>>   so I think this is quite strange ...
>>>
>>> openssl ciphers -V
>>>
>>> shows e.g.  ECDHE-ECDSA-DES-CBC3-SHA
>>> the site https://cc.dcsec.uni-hannover.de/ shows this:
>>> ECDHE-ECDSA-3DES-EDE-SHA
>>>
>>> are these the same cipher suites but two confusing names?
>>>
>>> Walter
>>>
>>>
>>>
>>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Somewhat conflicting configuration and strange behaviour

andrew cooke

well, i realised i couldn't answer the question seriously...  what is
ECDHE-ECDSA-3DES-EDE-SHA ?  the only reference i can find on the web is to
google chrome and firefox accepting it (a grep of openssl 1.0.1e fails to find
it).  does any server actually provide it?  if so, what mode does it use (EDE
is saying something about DES - how to build 3DES from DES - rather than
giving a mode, isn't it?)?

andrew



On Fri, Dec 13, 2013 at 08:51:44PM +0100, Erwann Abalea wrote:

> Don't regret it, it wasn't that bad ;)
>
> --
> Erwann ABALEA
>
> Le 13/12/2013 20:39, andrew cooke a écrit :
> >sorry, that was a bad joke i now regret sending.  andrew
> >
> >On Fri, Dec 13, 2013 at 04:01:23PM -0300, Andrew Cooke wrote:
> >>it dpends how many characters differ when sorted.
> >>
> >>in this case:
> >>
> >>ECDHE-ECDSA-DES-CBC3-SHA -> ----3AABCCCCDDDEEEEHHSSS
> >>                                    * *** **
> >>ECDHE-ECDSA-3DES-EDE-SHA -> ----3AACCDDDDEEEEEEHHSSS
> >>
> >>you can see (marked by *) that 6 characters don't match.
> >>
> >>now 6 is a triangular number, but the length of the entire cipher suite is 24,
> >>which isn't triangule (the closest is 21).
> >>
> >>so they're only going to inter-operate on tuesdays.
> >>
> >>andrew
> >>
> >>
> >>On Fri, Dec 13, 2013 at 07:30:02PM +0100, Walter H. wrote:
> >>>On 12.12.2013 14:16, Erwann Abalea wrote:
> >>>>It's not strange.
> >>>>You removed the RSA-* from client side, the result is that the
> >>>>server can't match anything in common between what the client
> >>>>proposed and what the server accepts. The error you get has been
> >>>>sent by the server.
> >>>>
> >>>The server is capable of ciphers DHE-* and others;
> >>>the list is quite longer than the avaiable ciphers of the client ...,
> >>>  so I think this is quite strange ...
> >>>
> >>>openssl ciphers -V
> >>>
> >>>shows e.g.  ECDHE-ECDSA-DES-CBC3-SHA
> >>>the site https://cc.dcsec.uni-hannover.de/ shows this:
> >>>ECDHE-ECDSA-3DES-EDE-SHA
> >>>
> >>>are these the same cipher suites but two confusing names?
> >>>
> >>>Walter
> >>>
> >>>
> >>>
> >>
> >______________________________________________________________________
> >OpenSSL Project                                 http://www.openssl.org
> >User Support Mailing List                    [hidden email]
> >Automated List Manager                           [hidden email]
> >
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Somewhat conflicting configuration and strange behaviour

Walter H.
On 13.12.2013 21:16, andrew cooke wrote:
> well, i realised i couldn't answer the question seriously...  what is
> ECDHE-ECDSA-3DES-EDE-SHA ?  the only reference i can find on the web is to
> google chrome and firefox accepting it (a grep of openssl 1.0.1e fails to find
> it).  does any server actually provide it?  if so, what mode does it use (EDE
> is saying something about DES - how to build 3DES from DES - rather than
> giving a mode, isn't it?)?
>
> andrew
>
exact this is my problem - I need a ciphersuite from the OpenSSL list,
that matches one of the FF list and doesn't make use of RSA for key
exchange ...

Thanks,
Walter


smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Somewhat conflicting configuration and strange behaviour

andrew cooke

well, not really, because in practice the name has to match, so you are stuck
(as the earlier answer says).

i guess the answer is somewhere in the nss code...

andrew


On Fri, Dec 13, 2013 at 10:04:52PM +0100, Walter H. wrote:

> On 13.12.2013 21:16, andrew cooke wrote:
> >well, i realised i couldn't answer the question seriously...  what is
> >ECDHE-ECDSA-3DES-EDE-SHA ?  the only reference i can find on the web is to
> >google chrome and firefox accepting it (a grep of openssl 1.0.1e fails to find
> >it).  does any server actually provide it?  if so, what mode does it use (EDE
> >is saying something about DES - how to build 3DES from DES - rather than
> >giving a mode, isn't it?)?
> >
> >andrew
> >
> exact this is my problem - I need a ciphersuite from the OpenSSL
> list, that matches one of the FF list and doesn't make use of RSA
> for key exchange ...
>
> Thanks,
> Walter
>


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Somewhat conflicting configuration and strange behaviour

Dr. Stephen Henson
In reply to this post by Walter H.
On Fri, Dec 13, 2013, Walter H. wrote:

> On 13.12.2013 21:16, andrew cooke wrote:
> >well, i realised i couldn't answer the question seriously...  what is
> >ECDHE-ECDSA-3DES-EDE-SHA ?  the only reference i can find on the web is to
> >google chrome and firefox accepting it (a grep of openssl 1.0.1e fails to find
> >it).  does any server actually provide it?  if so, what mode does it use (EDE
> >is saying something about DES - how to build 3DES from DES - rather than
> >giving a mode, isn't it?)?
> >
> >andrew
> >
> exact this is my problem - I need a ciphersuite from the OpenSSL
> list, that matches one of the FF list and doesn't make use of RSA
> for key exchange ...
>

How are you disabling RSA key exchange? If you disable RSA for authentication
too you'll hit problems if you don't have a non-RSA certificate. So for
example: ECDHE-ECDSA-3DES-EDE-SHA needs an ECDSA certificate (that's the same
as ECDHE-ECDSA-DES-CBC3-SHA).

You can disable RSA key exchange by appending the string !kRSA to the cipher
string, for example: "DEFAULT:!kRSA". Also if you want to support EDH
ciphersuites you need to set some DH parameters and for ECDH a suitable curve.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: [openssl-users] Somewhat conflicting configuration and strange behaviour

Dave Thompson-5
In reply to this post by Walter H.
> From: [hidden email] [mailto:owner-openssl-
> [hidden email]] On Behalf Of Walter H.
<snip>

> The server is capable of ciphers DHE-* and others;
> the list is quite longer than the avaiable ciphers of the client ...,
>   so I think this is quite strange ...
>
> openssl ciphers -V
>
> shows e.g.  ECDHE-ECDSA-DES-CBC3-SHA
> the site https://cc.dcsec.uni-hannover.de/ shows this:
> ECDHE-ECDSA-3DES-EDE-SHA
>
> are these the same cipher suites but two confusing names?
>
Yes. 3DES, 3DES*EDE, DES*EDE, DES*EDE*3, DES*3 and TDES are all
the same algorithm (whose rarely-used official name is TDEA).

'EDE' is superfluous now; back in the nineties when (what is
now) TDES was being developed there was some discussion
whether to use all 'forward' primitives (EEE) or a mix (EDE).
EDE was selected and has long been the only one used.

The TLS RFCs use _3DES_EDE_CBC_, originally named during
the time it was worthwhile to say EDE, and since retained for
compatibility and consistency. I believe SSL 3 spec did also.
OpenSSL for some reason, way back when, used -DES-CBC3-,
and now needs to keep that for compatibility, except on the
(much newer and disjoint) PSK and SRP suites.

Leaving out 'CBC' for block ciphers, as that website does
(for all not just TDES), seemed reasonable before TLSv1.2.
Now it's inconsistent and could be confusing.



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Somewhat conflicting configuration and strange behaviour

Walter H.
In reply to this post by Dr. Stephen Henson
On 14.12.2013 00:00, Dr. Stephen Henson wrote:
>
> How are you disabling RSA key exchange?
by setting all ciphers beginning with RSA to no in FF
>   If you disable RSA for authentication
> too you'll hit problems if you don't have a non-RSA certificate. So for
> example: ECDHE-ECDSA-3DES-EDE-SHA needs an ECDSA certificate (that's the same
> as ECDHE-ECDSA-DES-CBC3-SHA).
can you please give an example of such an ECDSA certificate?
> You can disable RSA key exchange by appending the string !kRSA to the cipher
> string, for example: "DEFAULT:!kRSA". Also if you want to support EDH
> ciphersuites you need to set some DH parameters and for ECDH a suitable curve.
this the option in squid "against" my client:

http_port 3128 ssl-bump generate-host-certificates=on
dynamic_cert_mem_cache_size=4MB cert=/etc/squid/cert/squid.pem
cipher=DEFAULT:!kRSA options=NO_SSLv2,SINGLE_DH_USE
dhparams=/etc/squid/cert/dhparam.pem

Thanks,
Walter



smime.p7s (7K) Download Attachment