PCI compliance issue - week ciphers are enabled by default
Locked
PCI compliance issue - week ciphers are enabled by default
 
|
We are trying to get PCI Compliance to be able to do credit card processing. We have resolved all the issues but for the "Weak Supported SSL Ciphers Suites on https(443/tcp)".
In a typical environment this is normally set at tomcat configuration/apache configuration level and in ofbiz these setting are in ofbiz-container.xml(root/frameworks/base/config). Any help to fine tune to configuration to solve this risk is greatly appreciated Our current setting: server - linux, centOS5 ssl certificate - supports upto 256-bit encryption security protocol used - TLSv1 (ofbiz_container.xml) cipher suite - "HIGH:MEDIUM:!SSLv2:!ADH:!aNULL:!eNULL:!NULL:!LOW" (Basically allows only high and medium ciphers of either SSLv3 or TLSv1)(ofbiz_container.xml) PCI rejection error: Risk factor : Medium / CVSS Base Score : 5.0 (CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:N) Plugin output : Here is the list of weak SSL ciphers supported by the remote server : Low Strength Ciphers (< 56-bit key) SSLv3 EXP-EDH-RSA-DES-CBC-SHA Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-DES-CBC-SHA Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-RC4-MD5 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export TLSv1 EXP-EDH-RSA-DES-CBC-SHA Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-DES-CBC-SHA Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-RC4-MD5 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export The fields above are : {OpenSSL ciphername} Kx={key exchange} Au={authentication} Enc={symmetric encryption method} Mac={message authentication code} {export flag} |
Re: PCI compliance issue - week ciphers are enabled by default
|
|
Hi Rajesh,
with a single MEDIUM criticality issue you are at compliance level 3, i.e. you will not put your PCI compliance at risk. However, you are right: We solve these issues at Apache level. I wonder how the auditors did approve your single layer OFBiz architecture (which I assume you will have since you are asking this audience for help in a Web Layer configuration issue)? If there is a solution in OFBiz configuration itself, I would like to know as well. However, I thought you would need to * introduce a Web Layer and * introduce a App Layer and PCI will require you to not allow un-authorized access from Web to App Layer. So how did you solve this architectural demand? Regards Carsten 2009/9/3 rajesh ramkumar <[hidden email]> > > We are trying to get PCI Compliance to be able to do credit card > processing. > We have resolved all the issues but for the "Weak Supported SSL Ciphers > Suites on https(443/tcp)". > > In a typical environment this is normally set at tomcat > configuration/apache > configuration level and in ofbiz these setting are in > ofbiz-container.xml(root/frameworks/base/config). Any help to fine tune to > configuration to solve this risk is greatly appreciated > > Our current setting: > server - linux, centOS5 > ssl certificate - supports upto 256-bit encryption > security protocol used - TLSv1 (ofbiz_container.xml) > cipher suite - "HIGH:MEDIUM:!SSLv2:!ADH:!aNULL:!eNULL:!NULL:!LOW" > (Basically > allows only high and medium ciphers of either SSLv3 or > TLSv1)(ofbiz_container.xml) > > PCI rejection error: > Risk factor : Medium / CVSS Base Score : 5.0 > (CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:N) Plugin output : Here is the list > of weak SSL ciphers supported by the remote server : Low Strength > Ciphers (< 56-bit key) SSLv3 EXP-EDH-RSA-DES-CBC-SHA > Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 export > EXP-DES-CBC-SHA Kx=RSA(512) Au=RSA Enc=DES(40) > Mac=SHA1 export EXP-RC4-MD5 Kx=RSA(512) > Au=RSA Enc=RC4(40) Mac=MD5 export TLSv1 > EXP-EDH-RSA-DES-CBC-SHA Kx=DH(512) Au=RSA Enc=DES(40) > Mac=SHA1 export EXP-DES-CBC-SHA Kx=RSA(512) > Au=RSA Enc=DES(40) Mac=SHA1 export EXP-RC4-MD5 > Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 > export The fields above are : {OpenSSL ciphername} Kx={key > exchange} Au={authentication} Enc={symmetric encryption method} > Mac={message authentication code} {export flag} > > > > -- > View this message in context: > http://www.nabble.com/PCI-compliance-issue---week-ciphers-are-enabled-by-default-tp25273745p25273745.html > Sent from the OFBiz - User mailing list archive at Nabble.com. > > -- Best Carsten Schinzer Waisenhausstr. 53a 80637 München Germany |
Re: PCI compliance issue - week ciphers are enabled by default
|
|
Hi carsten,
Thanks for the reply. As stated by yourself, we are on single layer OFBiz architecture and I have not come across any restrictions for getting PCI compliance based on this architecture. Can you please forward me links/website that mentions this restriction. Even if you introduce a web & application layer, i.e front your ofbiz server(server on which you run ofbiz) with apache using mod jk connector/ajp protocol, how are you restricting the access on http(80 or any) and https(443 or any) ports on the ofbiz server(internal tomcat). If you are running apache on a different server then, I would assume that you need to get both your servers audited for PCI compliance? If you are running both apache & ofbiz on the same server then you might have configured the http & https ports on internal tomcat to be different to 80 & 443, but even then the new ports can be hit from outside, so how did you deal with that. Any reply/help is greatly appreciated. regards Rajesh
|
|
|
Hi Rajesh,
If you use Apache web server to front OFBiz, you can restrict the OFBiz connector (AJP/1.3) to bind only to the loopback interface (127.0.0.1). I generally disable http and ssl connector and just keep the AJP/1.3. This way you OFBiz will not be accessible form outside world and only Apache web server running on the same host will communicate with OFBiz. Thanks, Raj rajesh ramkumar wrote: > Hi carsten, > > Thanks for the reply. > > As stated by yourself, we are on single layer OFBiz architecture and I have > not come across any restrictions for getting PCI compliance based on this > architecture. Can you please forward me links/website that mentions this > restriction. > > Even if you introduce a web & application layer, i.e front your ofbiz > server(server on which you run ofbiz) with apache using mod jk connector/ajp > protocol, how are you restricting the access on http(80 or any) and > https(443 or any) ports on the ofbiz server(internal tomcat). > > If you are running apache on a different server then, I would assume that > you need to get both your servers audited for PCI compliance? If you are > running both apache & ofbiz on the same server then you might have > configured the http & https ports on internal tomcat to be different to 80 & > 443, but even then the new ports can be hit from outside, so how did you > deal with that. > > Any reply/help is greatly appreciated. > > regards > Rajesh > > > > Carsten Schinzer wrote: > >> Hi Rajesh, >> >> >> with a single MEDIUM criticality issue you are at compliance level 3, i.e. >> you will not put your PCI compliance at risk. >> However, you are right: We solve these issues at Apache level. >> >> I wonder how the auditors did approve your single layer OFBiz architecture >> (which I assume you will have since you are asking this audience for help >> in >> a Web Layer configuration issue)? >> >> If there is a solution in OFBiz configuration itself, I would like to know >> as well. However, I thought you would need to >> * introduce a Web Layer and >> * introduce a App Layer >> and PCI will require you to not allow un-authorized access from Web to App >> Layer. So how did you solve this architectural demand? >> >> Regards >> >> >> Carsten >> >> >> 2009/9/3 rajesh ramkumar <[hidden email]> >> >> >>> We are trying to get PCI Compliance to be able to do credit card >>> processing. >>> We have resolved all the issues but for the "Weak Supported SSL Ciphers >>> Suites on https(443/tcp)". >>> >>> In a typical environment this is normally set at tomcat >>> configuration/apache >>> configuration level and in ofbiz these setting are in >>> ofbiz-container.xml(root/frameworks/base/config). Any help to fine tune >>> to >>> configuration to solve this risk is greatly appreciated >>> >>> Our current setting: >>> server - linux, centOS5 >>> ssl certificate - supports upto 256-bit encryption >>> security protocol used - TLSv1 (ofbiz_container.xml) >>> cipher suite - "HIGH:MEDIUM:!SSLv2:!ADH:!aNULL:!eNULL:!NULL:!LOW" >>> (Basically >>> allows only high and medium ciphers of either SSLv3 or >>> TLSv1)(ofbiz_container.xml) >>> >>> PCI rejection error: >>> Risk factor : Medium / CVSS Base Score : 5.0 >>> (CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:N) Plugin output : Here is the list >>> of weak SSL ciphers supported by the remote server : Low Strength >>> Ciphers (< 56-bit key) SSLv3 EXP-EDH-RSA-DES-CBC-SHA >>> Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 export >>> EXP-DES-CBC-SHA Kx=RSA(512) Au=RSA Enc=DES(40) >>> Mac=SHA1 export EXP-RC4-MD5 Kx=RSA(512) >>> Au=RSA Enc=RC4(40) Mac=MD5 export TLSv1 >>> EXP-EDH-RSA-DES-CBC-SHA Kx=DH(512) Au=RSA Enc=DES(40) >>> Mac=SHA1 export EXP-DES-CBC-SHA Kx=RSA(512) >>> Au=RSA Enc=DES(40) Mac=SHA1 export EXP-RC4-MD5 >>> Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 >>> export The fields above are : {OpenSSL ciphername} Kx={key >>> exchange} Au={authentication} Enc={symmetric encryption method} >>> Mac={message authentication code} {export flag} >>> >>> >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/PCI-compliance-issue---week-ciphers-are-enabled-by-default-tp25273745p25273745.html >>> Sent from the OFBiz - User mailing list archive at Nabble.com. >>> >>> >>> >> -- >> >> Best >> >> Carsten Schinzer >> >> Waisenhausstr. 53a >> 80637 München >> Germany >> >> >> > > |
Re: PCI compliance issue - week ciphers are enabled by default
Administrator
|
Yes this sounds like the better choice indeed
Jacques From: "Raj Saini" <[hidden email]> > Hi Rajesh, > > If you use Apache web server to front OFBiz, you can restrict the OFBiz connector (AJP/1.3) to bind only to the loopback interface > (127.0.0.1). I generally disable http and ssl connector and just keep the AJP/1.3. This way you OFBiz will not be accessible form > outside world and only Apache web server running on the same host will communicate with OFBiz. > > Thanks, > > Raj > > rajesh ramkumar wrote: >> Hi carsten, >> >> Thanks for the reply. >> >> As stated by yourself, we are on single layer OFBiz architecture and I have >> not come across any restrictions for getting PCI compliance based on this >> architecture. Can you please forward me links/website that mentions this >> restriction. >> >> Even if you introduce a web & application layer, i.e front your ofbiz >> server(server on which you run ofbiz) with apache using mod jk connector/ajp >> protocol, how are you restricting the access on http(80 or any) and >> https(443 or any) ports on the ofbiz server(internal tomcat). >> If you are running apache on a different server then, I would assume that >> you need to get both your servers audited for PCI compliance? If you are >> running both apache & ofbiz on the same server then you might have >> configured the http & https ports on internal tomcat to be different to 80 & >> 443, but even then the new ports can be hit from outside, so how did you >> deal with that. >> Any reply/help is greatly appreciated. >> >> regards >> Rajesh >> >> >> >> Carsten Schinzer wrote: >> >>> Hi Rajesh, >>> >>> >>> with a single MEDIUM criticality issue you are at compliance level 3, i.e. >>> you will not put your PCI compliance at risk. >>> However, you are right: We solve these issues at Apache level. >>> >>> I wonder how the auditors did approve your single layer OFBiz architecture >>> (which I assume you will have since you are asking this audience for help >>> in >>> a Web Layer configuration issue)? >>> >>> If there is a solution in OFBiz configuration itself, I would like to know >>> as well. However, I thought you would need to >>> * introduce a Web Layer and >>> * introduce a App Layer >>> and PCI will require you to not allow un-authorized access from Web to App >>> Layer. So how did you solve this architectural demand? >>> >>> Regards >>> >>> >>> Carsten >>> >>> >>> 2009/9/3 rajesh ramkumar <[hidden email]> >>> >>> >>>> We are trying to get PCI Compliance to be able to do credit card >>>> processing. >>>> We have resolved all the issues but for the "Weak Supported SSL Ciphers >>>> Suites on https(443/tcp)". >>>> >>>> In a typical environment this is normally set at tomcat >>>> configuration/apache >>>> configuration level and in ofbiz these setting are in >>>> ofbiz-container.xml(root/frameworks/base/config). Any help to fine tune >>>> to >>>> configuration to solve this risk is greatly appreciated >>>> >>>> Our current setting: >>>> server - linux, centOS5 >>>> ssl certificate - supports upto 256-bit encryption >>>> security protocol used - TLSv1 (ofbiz_container.xml) >>>> cipher suite - "HIGH:MEDIUM:!SSLv2:!ADH:!aNULL:!eNULL:!NULL:!LOW" >>>> (Basically >>>> allows only high and medium ciphers of either SSLv3 or >>>> TLSv1)(ofbiz_container.xml) >>>> >>>> PCI rejection error: >>>> Risk factor : Medium / CVSS Base Score : 5.0 >>>> (CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:N) Plugin output : Here is the list >>>> of weak SSL ciphers supported by the remote server : Low Strength >>>> Ciphers (< 56-bit key) SSLv3 EXP-EDH-RSA-DES-CBC-SHA >>>> Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 export >>>> EXP-DES-CBC-SHA Kx=RSA(512) Au=RSA Enc=DES(40) >>>> Mac=SHA1 export EXP-RC4-MD5 Kx=RSA(512) >>>> Au=RSA Enc=RC4(40) Mac=MD5 export TLSv1 >>>> EXP-EDH-RSA-DES-CBC-SHA Kx=DH(512) Au=RSA Enc=DES(40) >>>> Mac=SHA1 export EXP-DES-CBC-SHA Kx=RSA(512) >>>> Au=RSA Enc=DES(40) Mac=SHA1 export EXP-RC4-MD5 >>>> Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 >>>> export The fields above are : {OpenSSL ciphername} Kx={key >>>> exchange} Au={authentication} Enc={symmetric encryption method} >>>> Mac={message authentication code} {export flag} >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://www.nabble.com/PCI-compliance-issue---week-ciphers-are-enabled-by-default-tp25273745p25273745.html >>>> Sent from the OFBiz - User mailing list archive at Nabble.com. >>>> >>>> >>>> >>> -- >>> >>> Best >>> >>> Carsten Schinzer >>> >>> Waisenhausstr. 53a >>> 80637 München >>> Germany >>> >>> >>> >> >> > |
Re: PCI compliance issue - week ciphers are enabled by default
|
|
In reply to this post by rajesh ramkumar
Well, the trick is to separate your Apache as an access point in the DMZ and
put network-level restricitons (Layer 3, i.e. TCP/IP) on the traffic between apache and ofbiz in this case. That will suffice PCI requirements. For your other question: A two-layer layout is IMHP strongly imposed by section 1 of the PCI requirements document v1.2. If you do not have that, check https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml I am sure you will agree that a standalone instance with your cardholder data in the DMZ (or a single zone exposed to internet traffic) will not suffice these requirements. Are you already in the audit process? Or just preparing? Regards Carsten 2009/9/3 rajesh ramkumar <[hidden email]> > > Hi carsten, > > Thanks for the reply. > > As stated by yourself, we are on single layer OFBiz architecture and I have > not come across any restrictions for getting PCI compliance based on this > architecture. Can you please forward me links/website that mentions this > restriction. > > Even if you introduce a web & application layer, i.e front your ofbiz > server(server on which you run ofbiz) with apache using mod jk > connector/ajp > protocol, how are you restricting the access on http(80 or any) and > https(443 or any) ports on the ofbiz server(internal tomcat). > > If you are running apache on a different server then, I would assume that > you need to get both your servers audited for PCI compliance? If you are > running both apache & ofbiz on the same server then you might have > configured the http & https ports on internal tomcat to be different to 80 > & > 443, but even then the new ports can be hit from outside, so how did you > deal with that. > > Any reply/help is greatly appreciated. > > regards > Rajesh > > > > Carsten Schinzer wrote: > > > > Hi Rajesh, > > > > > > with a single MEDIUM criticality issue you are at compliance level 3, > i.e. > > you will not put your PCI compliance at risk. > > However, you are right: We solve these issues at Apache level. > > > > I wonder how the auditors did approve your single layer OFBiz > architecture > > (which I assume you will have since you are asking this audience for help > > in > > a Web Layer configuration issue)? > > > > If there is a solution in OFBiz configuration itself, I would like to > know > > as well. However, I thought you would need to > > * introduce a Web Layer and > > * introduce a App Layer > > and PCI will require you to not allow un-authorized access from Web to > App > > Layer. So how did you solve this architectural demand? > > > > Regards > > > > > > Carsten > > > > > > 2009/9/3 rajesh ramkumar <[hidden email]> > > > >> > >> We are trying to get PCI Compliance to be able to do credit card > >> processing. > >> We have resolved all the issues but for the "Weak Supported SSL Ciphers > >> Suites on https(443/tcp)". > >> > >> In a typical environment this is normally set at tomcat > >> configuration/apache > >> configuration level and in ofbiz these setting are in > >> ofbiz-container.xml(root/frameworks/base/config). Any help to fine tune > >> to > >> configuration to solve this risk is greatly appreciated > >> > >> Our current setting: > >> server - linux, centOS5 > >> ssl certificate - supports upto 256-bit encryption > >> security protocol used - TLSv1 (ofbiz_container.xml) > >> cipher suite - "HIGH:MEDIUM:!SSLv2:!ADH:!aNULL:!eNULL:!NULL:!LOW" > >> (Basically > >> allows only high and medium ciphers of either SSLv3 or > >> TLSv1)(ofbiz_container.xml) > >> > >> PCI rejection error: > >> Risk factor : Medium / CVSS Base Score : 5.0 > >> (CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:N) Plugin output : Here is the list > >> of weak SSL ciphers supported by the remote server : Low Strength > >> Ciphers (< 56-bit key) SSLv3 EXP-EDH-RSA-DES-CBC-SHA > >> Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 export > >> EXP-DES-CBC-SHA Kx=RSA(512) Au=RSA Enc=DES(40) > >> Mac=SHA1 export EXP-RC4-MD5 Kx=RSA(512) > >> Au=RSA Enc=RC4(40) Mac=MD5 export TLSv1 > >> EXP-EDH-RSA-DES-CBC-SHA Kx=DH(512) Au=RSA Enc=DES(40) > >> Mac=SHA1 export EXP-DES-CBC-SHA Kx=RSA(512) > >> Au=RSA Enc=DES(40) Mac=SHA1 export EXP-RC4-MD5 > >> Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 > >> export The fields above are : {OpenSSL ciphername} Kx={key > >> exchange} Au={authentication} Enc={symmetric encryption method} > >> Mac={message authentication code} {export flag} > >> > >> > >> > >> -- > >> View this message in context: > >> > http://www.nabble.com/PCI-compliance-issue---week-ciphers-are-enabled-by-default-tp25273745p25273745.html > >> Sent from the OFBiz - User mailing list archive at Nabble.com. > >> > >> > > > > > > -- > > > > Best > > > > Carsten Schinzer > > > > Waisenhausstr. 53a > > 80637 München > > Germany > > > > > > -- > View this message in context: > http://www.nabble.com/PCI-compliance-issue---week-ciphers-are-enabled-by-default-tp25273745p25275109.html > Sent from the OFBiz - User mailing list archive at Nabble.com. > > -- Best Carsten Schinzer Waisenhausstr. 53a 80637 München Germany |
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |