summaryrefslogtreecommitdiff
path: root/puppet/modules/site_apache/files
AgeCommit message (Collapse)Author
2017-01-18Rename extensions module to autorestartTulio Casagrande
2017-01-18Add apache auto-restart extension fileTulio Casagrande
2016-09-01added support for Let's Encryptelijah
2016-06-16Disable the Trace method (#8195)Micah
The Trace method is enabled because of the Apache module, but it is not the default in Debian, and it should not be enabled, for more information see the following: https://www.kb.cert.org/vuls/id/867593 Change-Id: I06a06ae679dbf7049f26a017125b61e5e38f6268
2015-05-26Implement weakdh recommendations for cipher suites (#7024)Micah Anderson
This is a first step mitigation until we can have a newer apache that will allow us to specify dh parameters other than the default. Change-Id: Ibfcee53b331e8919466027dde1a93117b5210d9d
2014-12-22Adds a ssl_common.inc file to use inside vhosts for the SSL config (solves ↵guido
#5103) Change-Id: I717bf7ca2c5679165a99370c4540f8b8dc1a48ea
2013-08-21Set apache header X-Frame-Options: "DENY"Micah Anderson
The LEAP web application can be displayed inside other pages using an HTML iframe. Therefore, an attacker can embed parts of the LEAP application inside of a webpage they control. They can then use special style properties to disguise the embedded page. By tricking a user in to clicking in the iframe, the attacker can coerce the user in to performing unintended actions within the LEAP web application. An attacker creates a website that embeds the LEAP web application in an iframe. They then create an HTML /JavaScript game on the same page that involves clicking and dragging sprites. When a user plays the game, they are in fact dragging new text values in to the ‘‘Change Password’’ form in the LEAP web app, which is hidden behind the game using As long as iframe embedding is not required in the normal usage of the application, the X-Frame-Options header should be added to prevent browsers from displaying the web application in frames on other origins. This has also been set in the webapp Change-Id: I9e26ae32de4b7b6a327196838d0fa410648f107d
2013-08-21Disable verbose, identifying apache headers (#3462):Micah Anderson
. Disable ServerSignature . Set ServerTokens Prod . unset the X-Powered-By and X-Runtime apache headers Change-Id: Iddb2cb9a0465bc7f657581adaacbbf748479fd7a
2013-03-14remove apache ssl proxy in preparation of replacing it with a stunnel setupMicah Anderson
This presents us with an interesting problem of deprecation. We need to manage the removal of something that we previously installed in any released code. How long we carry the puppet code that removes raises some interesting questions: do we require that someone who deployed version 1 (where the apache ssl proxy was deployed) of the platform upgrade first to version 2 (where we remove the apache ssl proxy) before they upgrade to version 3 (where the apache ssl proxy removal is no longer present) -- or do we allow people to skip versions?
2012-12-10couchdb: use x509 module to deploy certs (fixes #1063)varac
2012-11-03configure apache ssl proxy for couchdbvarac