By editing main.inc.php
setting debug_level = 8 and log_session = true. I got a /var/log/roundcube/session file that says:
[27-Dec-2012 17:46:08 -0500]: Session authentication failed for 5uhp5ktuaec7bhoj8qgl4slli2; invalid auth cookie sent
I see there is a message about this at:
http://www.roundcubeforum.net/index.php?topic=10654.0
"turned off $rcmail_config['force_https'] and $rcmail_config['use_https'] (set both to False)"
Is this the proper action to take for this error? I already have force_https = false.
On 12/27/2012 05:57 PM, Robert Moskowitz wrote:
By editing main.inc.php
setting debug_level = 8 and log_session = true. I got a /var/log/roundcube/session file that says:
[27-Dec-2012 17:46:08 -0500]: Session authentication failed for 5uhp5ktuaec7bhoj8qgl4slli2; invalid auth cookie sent
I see there is a message about this at:
http://www.roundcubeforum.net/index.php?topic=10654.0
"turned off $rcmail_config['force_https'] and $rcmail_config['use_https'] (set both to False)"
Is this the proper action to take for this error? I already have force_https = false.
I changed use_https = false and now am in. Now to ask why this was needed as true is the default.
hmmm. Thinking (really!) I should change it back and try https:/.../webmail and see if it works. If it does, I need to add a force redirect to the roundcube.conf. Thinking more, this is reasonable as this is how my current squirrelmail works.
On 27/12/2012 23:17, Robert Moskowitz wrote:
hmmm. Thinking (really!) I should change it back and try https:/.../webmail and see if it works. If it does, I need to add a force redirect to the roundcube.conf. Thinking more, this is reasonable as this is how my current squirrelmail works.
But shouldn't people be accessing it via https anyway? I mean without the need for a redirection? Adding a redirection increases security issues (for your site) so I personally would not be keen to do that.
-- Jan
Am 28.12.2012 00:24, schrieb Jan M. Dziewulski:
On 27/12/2012 23:17, Robert Moskowitz wrote:
hmmm. Thinking (really!) I should change it back and try https:/.../webmail and see if it works. If it does, I need to add a force redirect to the roundcube.conf. Thinking more, this is reasonable as this is how my current squirrelmail works.
But shouldn't people be accessing it via https anyway? I mean without the need for a redirection? Adding a redirection increases security issues (for your site) so I personally would not be keen to do that
it does not if it is done right
<Directory "roundcube-dir"> php_admin_flag session.cookie_secure "1"
</Directory>
this makes sure that there will NEVER a client send the session cookie unencrypted, if you get a external security audit and do not use tis setting for https sites you will get warned by the auditor and if not he did not make his job!
On 12/27/2012 06:40 PM, Reindl Harald wrote:
Am 28.12.2012 00:24, schrieb Jan M. Dziewulski:
On 27/12/2012 23:17, Robert Moskowitz wrote:
hmmm. Thinking (really!) I should change it back and try https:/.../webmail and see if it works. If it does, I need to add a force redirect to the roundcube.conf. Thinking more, this is reasonable as this is how my current squirrelmail works.
But shouldn't people be accessing it via https anyway? I mean without the need for a redirection? Adding a redirection increases security issues (for your site) so I personally would not be keen to do that
My little bit of testing gives the user a bad experience if they use http://fqdn/webmail. The ajax error is so cryptic. I suppose with some digging I can find a way to get it to say, "use https:// like you were instructed!" instead. Until I do, I tend towrad a forced redirect to https.
As for security issues for my site? What, yet another DOS attack with TLS costs to any robo that hits on my webmail url?
My expertise is in designing security protocols, not impact of force using them. ;)
it does not if it is done right
<Directory "roundcube-dir"> php_admin_flag session.cookie_secure "1"
</Directory>
this makes sure that there will NEVER a client send the session cookie unencrypted, if you get a external security audit and do not use tis setting for https sites you will get warned by the auditor and if not he did not make his job!
Perhaps I am implementing this wrong on my server. My roundcubemail.conf has
<Directory /usr/share/roundcubemail/> Order Deny,Allow Allow from all
</Directory>
Am I suppose to put your <Directory "roundcube-dir"> ...
after this entry or the php_admin_flag in the one I have?
What do you use for force_https and use_https?
Am 28.12.2012 01:27, schrieb Robert Moskowitz:
My little bit of testing gives the user a bad experience if they use http://fqdn/webmail. The ajax error is so cryptic. I suppose with some digging I can find a way to get it to say, "use https:// like you were instructed!" instead. Until I do, I tend towrad a forced redirect to https.
force redirect
As for security issues for my site? What, yet another DOS attack with TLS costs to any robo that hits on my webmail url?
if you are CPU bound because TLS and a robot you have other problems like too slow hardware, these days and with intel AES-NI it costs zero
My expertise is in designing security protocols, not impact of force using them. ;)
it does not if it is done right
<Directory "roundcube-dir"> php_admin_flag session.cookie_secure "1"
</Directory>
this makes sure that there will NEVER a client send the session cookie unencrypted, if you get a external security audit and do not use tis setting for https sites you will get warned by the auditor and if not he did not make his job!
Perhaps I am implementing this wrong on my server. My roundcubemail.conf has
<Directory /usr/share/roundcubemail/> Order Deny,Allow Allow from all
</Directory>
Am I suppose to put your <Directory "roundcube-dir"> ... after this entry or the php_admin_flag in the one I have?
jesus christ put it in your <Directory /usr/share/roundcubemail/> don't get me wrong but it should be pretty clear for anybody that <Directory "roundcube-dir"> is a example for mod_php basics
What do you use for force_https and use_https?
some lines of code in any php-file like configuration-includes which is always loaded, make sure it is included BEFORE any output starts because http-headers can not be pushed after output of http-body started
if(PHP_SAPI != 'cli' && empty($_SERVER['HTTPS'])) { header($_SERVER['SERVER_PROTOCOL'] . ' 301 Moved Permanently', true, 301); exit(header('Location: https://yourhostname/your-install-dir/', true, 301)); }
I thank you for your time and effort. I have some notes to read and will work on this tomorrow. this all shows how woefully rusty on apache config I allowed myself to become while doing other things.
On 12/27/2012 07:38 PM, Reindl Harald wrote:
Am 28.12.2012 01:27, schrieb Robert Moskowitz:
My little bit of testing gives the user a bad experience if they use http://fqdn/webmail. The ajax error is so cryptic. I suppose with some digging I can find a way to get it to say, "use https:// like you were instructed!" instead. Until I do, I tend towrad a forced redirect to https.
force redirect
As for security issues for my site? What, yet another DOS attack with TLS costs to any robo that hits on my webmail url?
if you are CPU bound because TLS and a robot you have other problems like too slow hardware, these days and with intel AES-NI it costs zero
My expertise is in designing security protocols, not impact of force using them. ;)
it does not if it is done right
<Directory "roundcube-dir"> php_admin_flag session.cookie_secure "1"
</Directory>
this makes sure that there will NEVER a client send the session cookie unencrypted, if you get a external security audit and do not use tis setting for https sites you will get warned by the auditor and if not he did not make his job!
Perhaps I am implementing this wrong on my server. My roundcubemail.conf has
<Directory /usr/share/roundcubemail/> Order Deny,Allow Allow from all
</Directory>
Am I suppose to put your <Directory "roundcube-dir"> ... after this entry or the php_admin_flag in the one I have?
jesus christ put it in your <Directory /usr/share/roundcubemail/> don't get me wrong but it should be pretty clear for anybody that <Directory "roundcube-dir"> is a example for mod_php basics
What do you use for force_https and use_https?
some lines of code in any php-file like configuration-includes which is always loaded, make sure it is included BEFORE any output starts because http-headers can not be pushed after output of http-body started
if(PHP_SAPI != 'cli' && empty($_SERVER['HTTPS'])) { header($_SERVER['SERVER_PROTOCOL'] . ' 301 Moved Permanently', true, 301); exit(header('Location: https://yourhostname/your-install-dir/', true, 301)); }
Roundcube Users mailing list users@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/users
Harald,
I am beginning to see what you are doing; through some foggy glasses.
Still need to read more, and today was not a reading day. I am
struggling to understand the attack space.
How can the user submit their cookie over an non-ssl connection when the server redirects everything to https? The only senario I have come up with is with the login screen in front of them, the user changes the method to http, enters in their data and sends?
So I have been running SquirrelMail as a virtual host over https and here the jist of what I have used:
<VirtualHost *:443>
ServerName webmail
ServerAlias webmail.foo.com
SSLEngine On
SSLCertificateFile ...crt
SSLCertificateKeyFile ...key
DocumentRoot /usr/share/squirrelmail
<Directory "/usr/share/squirrelmail">
...
</Directory>
</VirtualHost>
Any connection to http://webmail.foo.com gets returned as https://webmail.foo.com It took a bit of reading to get to this setup.
I will probably have to check with wireshark about what is going on if I change the method to http for any screen and what happens after login.
I do want to run Roundcube as a virtual host.
On 12/27/2012 06:40 PM, Reindl Harald wrote:
Am 28.12.2012 00:24, schrieb Jan M. Dziewulski:
On 27/12/2012 23:17, Robert Moskowitz wrote:
hmmm. Thinking (really!) I should change it back and try https:/.../webmail and see if it works. If it does, I need to add a force redirect to the roundcube.conf. Thinking more, this is reasonable as this is how my current squirrelmail works.
But shouldn't people be accessing it via https anyway? I mean without the need for a redirection? Adding a redirection increases security issues (for your site) so I personally would not be keen to do that
it does not if it is done right
<Directory "roundcube-dir"> php_admin_flag session.cookie_secure "1"
</Directory>
this makes sure that there will NEVER a client send the session cookie unencrypted, if you get a external security audit and do not use tis setting for https sites you will get warned by the auditor and if not he did not make his job!
Am 28.12.2012 20:06, schrieb Robert Moskowitz:
Harald,
I am beginning to see what you are doing; through some foggy glasses. Still need to read more, and today was not a reading day. I am struggling to understand the attack space.
How can the user submit their cookie over an non-ssl connection when the server redirects everything to https? The only senario I have come up with is with the login screen in front of them, the user changes the method to http, enters in their data and sends?
because the browser sends cookies with the HTTP-HEADER at the first connect the redirect from the server is also a header of the RESPONSE at this time the cookie was already sent unencrypted
Robert Moskowitz skrev den 2012-12-28 20:06:
Any connection to http://webmail.foo.com gets returned as https://webmail.foo.com It took a bit of reading to get to this setup.
http:// link should be seperate documentroot in apache with a diff content on that homepage that just say use https:// to get webmail access
in apache its 2 virtual host, not one, see apache logs to confirm that it works, webmail should never use http link in anyway, explain that on the webmail.foo.com if users use http and not https, then you dont need more security like other try to make as a workaround with redirects
apache virtualhosts is dokumented very well to get this to work
Am 28.12.2012 20:19, schrieb Benny Pedersen:
Robert Moskowitz skrev den 2012-12-28 20:06:
Any connection to http://webmail.foo.com gets returned as https://webmail.foo.com It took a bit of reading to get to this setup.
http:// link should be seperate documentroot in apache with a diff content on that homepage that just say use https:// to get webmail access
you did still not understand basics
if the cookies itself are not flagged with "secure only" the different docroot does not help in any way - you can place any redirect, info-page or whatever to the http:// site but after get the cookie from https:// roundcube and call the http// URL you will send your cookie UNECNRYPTED
why?
because cookies are DOMAIN based the domain is the same
Reindl Harald skrev den 2012-12-28 20:22:
because cookies are DOMAIN based the domain is the same
and you are not using roundcube ?
if roundcube have this kind of security problems please dokument it as a ticket so it gets fixed in php code, for the apache setup i still keep what i say to not use redirecting
On 12/28/2012 02:09 PM, Reindl Harald wrote:
Am 28.12.2012 20:06, schrieb Robert Moskowitz:
Harald,
I am beginning to see what you are doing; through some foggy glasses. Still need to read more, and today was not a reading day. I am struggling to understand the attack space.
How can the user submit their cookie over an non-ssl connection when the server redirects everything to https? The only senario I have come up with is with the login screen in front of them, the user changes the method to http, enters in their data and sends?
because the browser sends cookies with the HTTP-HEADER at the first connect the redirect from the server is also a header of the RESPONSE at this time the cookie was already sent unencrypted
Ah, such brilliance in overhead reduction.
So your little bit would have to change the cookie content so that the browser is informed that this cookie is only to be sent over a secure connection? Only way I see to stop this behavior is for the cookie to be flagged.
Am 28.12.2012 20:33, schrieb Benny Pedersen:
Reindl Harald skrev den 2012-12-28 20:22:
because cookies are DOMAIN based the domain is the same
and you are not using roundcube ?
if roundcube have this kind of security problems please dokument it as a ticket so it gets fixed in php code, for the apache setup i still keep what i say to not use redirecting
this has NOTHING to do with roundcube it is your lacking knowledge of HTTP basics
only idiots would configure a different docroot and hope that whatever used software is respsonsible to make sure that the browser only send abck cookies over https while skilled admins make sure this case in the docroot configuration independent of any script running on the host
Am 28.12.2012 20:35, schrieb Robert Moskowitz:
On 12/28/2012 02:09 PM, Reindl Harald wrote:
Am 28.12.2012 20:06, schrieb Robert Moskowitz:
Harald,
I am beginning to see what you are doing; through some foggy glasses. Still need to read more, and today was not a reading day. I am struggling to understand the attack space.
How can the user submit their cookie over an non-ssl connection when the server redirects everything to https? The only senario I have come up with is with the login screen in front of them, the user changes the method to http, enters in their data and sends?
because the browser sends cookies with the HTTP-HEADER at the first connect the redirect from the server is also a header of the RESPONSE at this time the cookie was already sent unencrypted
Ah, such brilliance in overhead reduction.
So your little bit would have to change the cookie content so that the browser is informed that this cookie is only to be sent over a secure connection? Only way I see to stop this behavior is for the cookie to be flagged.
<Directory "/usr/share/roundcube"> php_admin_flag session.cookie_secure "1"
<Directory>
which is still explaind yesterday http://php.net/manual/en/session.configuration.php#ini.session.cookie-secure
On 12/28/2012 02:22 PM, Reindl Harald wrote:
Am 28.12.2012 20:19, schrieb Benny Pedersen:
Robert Moskowitz skrev den 2012-12-28 20:06:
Any connection to http://webmail.foo.com gets returned as https://webmail.foo.com It took a bit of reading to get to this setup.
http:// link should be seperate documentroot in apache with a diff content on that homepage that just say use https:// to get webmail access
you did still not understand basics
if the cookies itself are not flagged with "secure only" the different docroot does not help in any way
This basic browser behavior fact is critical in understanding the attack space against cookie content.
Thank you for the edification.
- you can place
any redirect, info-page or whatever to the http:// site but after get the cookie from https:// roundcube and call the http// URL you will send your cookie UNECNRYPTED
why?
because cookies are DOMAIN based the domain is the same
Reindl Harald skrev den 2012-12-28 20:37:
in the docroot configuration independent of any script running on the host
start dokumenting it in ticket if its security problems in roundcube, no need to be flameing personly
should not be impossible to do from geeks :)
On 12/28/2012 02:39 PM, Reindl Harald wrote:
Am 28.12.2012 20:35, schrieb Robert Moskowitz:
On 12/28/2012 02:09 PM, Reindl Harald wrote:
Am 28.12.2012 20:06, schrieb Robert Moskowitz:
Harald,
I am beginning to see what you are doing; through some foggy glasses. Still need to read more, and today was not a reading day. I am struggling to understand the attack space.
How can the user submit their cookie over an non-ssl connection when the server redirects everything to https? The only senario I have come up with is with the login screen in front of them, the user changes the method to http, enters in their data and sends?
because the browser sends cookies with the HTTP-HEADER at the first connect the redirect from the server is also a header of the RESPONSE at this time the cookie was already sent unencrypted
Ah, such brilliance in overhead reduction.
So your little bit would have to change the cookie content so that the browser is informed that this cookie is only to be sent over a secure connection? Only way I see to stop this behavior is for the cookie to be flagged.
<Directory "/usr/share/roundcube"> php_admin_flag session.cookie_secure "1"
<Directory>
which is still explaind yesterday http://php.net/manual/en/session.configuration.php#ini.session.cookie-secure
Yes, I got that and now 'getting it'. Just nit-picking, you use "1" the manual says boolean with the default of off, so just two ways of representing boolean, numeric or label. In my way of thinking (hey, I am dyslexic) labels reduce confusion because there is only off and on (no maybes) while numeric raise a question of "2"...?
On 12/28/2012 03:09 PM, Benny Pedersen wrote:
Reindl Harald skrev den 2012-12-28 20:37:
in the docroot configuration independent of any script running on the host
start dokumenting it in ticket if its security problems in roundcube, no need to be flameing personly
It is an interesting question, should this behaviour be default? It seems that Roundcube works from a default non-secured senario and expects those that want to secure it to know what to do.
I suspect you can open as many tickets as you choose, the developers will most likely NOT take a secure by default posture.
We (the security area in the IETF) have worked on this for years to get basic default security into protocol and application design. It is tilting at windmills.
should not be impossible to do from geeks :)
Roundcube Users mailing list users@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/users
Am 28.12.2012 21:09, schrieb Benny Pedersen:
Reindl Harald skrev den 2012-12-28 20:37:
in the docroot configuration independent of any script running on the host
start dokumenting it in ticket if its security problems in roundcube
it is NOT a security problem of roundcube it is the job of the dmaned admin
roundcube does not need to smell if hhtps is a topic there are many environments where it is not
no need to be flameing personly
you have not a single idea how i sound if i start to flame
should not be impossible to do from geeks :)
to lern-resistent trolls? why should i spend any energy to search nice words for you?
Robert Moskowitz skrev den 28-12-2012 21:30:
It is an interesting question, should this behaviour be default? It seems that Roundcube works from a default non-secured senario and expects those that want to secure it to know what to do.
it should be coded with secure in mind no matter how stupid webmasters is :)
please note that i did not say idiots, ups i did now :)
I suspect you can open as many tickets as you choose, the developers will most likely NOT take a secure by default posture.
hmm okay with me if both http and https is secure with the same php code, i dont think its should be a consern in end users to make sure its safe to use, if this is insecure by default i ask users to use there apple hardware :)
We (the security area in the IETF) have worked on this for years to get basic default security into protocol and application design. It is tilting at windmills.
there is so much problems in security that all users drop it and run unsecure to get it simple, now tcpdump kids can use there logins in stolen passwords / logins, we could start using non ssl imap/pop3/submission aswell to make it even better for all parts
Am 28.12.2012 22:45, schrieb Benny Pedersen:
Robert Moskowitz skrev den 28-12-2012 21:30:
It is an interesting question, should this behaviour be default? It seems that Roundcube works from a default non-secured senario and expects those that want to secure it to know what to do.
it should be coded with secure in mind no matter how stupid webmasters is :)
boah it is not the job of php-software to configure your webserver
this is the job of the admin if he is too stupid and/or not skilled enough he sould do a job where his qualification is good enugh and not call gimself admin
if this is insecure by default i ask users to use there apple hardware :)
can you little idiot please leave us fuck in peace?
On Fri, 2012-12-28 at 15:12 -0500, Robert Moskowitz wrote:
So your little bit would have to change the cookie content so that the browser is informed that this cookie is only to be sent over a secure connection? Only way I see to stop this behavior is for the cookie to be flagged.
<Directory "/usr/share/roundcube"> php_admin_flag session.cookie_secure "1"
<Directory>
If you use multiple virtual hosts, you dont need to put it inside a directory, you can put it in between<virtualhost> ... </virtualhost>
which is still explaind yesterday http://php.net/manual/en/session.configuration.php#ini.session.cookie-secure
Yes, I got that and now 'getting it'. Just nit-picking, you use "1" the manual says boolean with the default of off, so just two ways of representing boolean, numeric or label. In my way of thinking (hey, I am dyslexic) labels reduce confusion because there is only off and on (no maybes) while numeric raise a question of "2"...?
This is because you are not talking directly to php, you are talking to httpd, and asking it to pass onto say mod_php, so it must be in a format that they talk to each other in.
Like If you've ever tried to manipulate error reporting you'll know you
cant use
"php_admin_value error_reporting E_ALL & ~E_NOTICE & ~E_DEPRECATED" -
which will fail, you need to use
"php_admin_value error_reporting 22519" to get the actual effect of
E_ALL & ~E_NOTICE & ~E_DEPRECATED.
Get back to me with your details.
BEST REGARDS, SILVER FINANCE FIRM.
From: Reindl Harald h.reindl@thelounge.net To: users@lists.roundcube.net Sent: Friday, December 28, 2012 11:37 AM Subject: Re: [RCU] locking in https - Re: invalid auth cookie
Am 28.12.2012 20:33, schrieb Benny Pedersen:
Reindl Harald skrev den 2012-12-28 20:22:
because cookies are DOMAIN based the domain is the same
and you are not using roundcube ?
if roundcube have this kind of security problems please dokument it as a ticket so it gets fixed in php code, for the apache setup i still keep what i say to not use redirecting
this has NOTHING to do with roundcube it is your lacking knowledge of HTTP basics
only idiots would configure a different docroot and hope that whatever used software is respsonsible to make sure that the browser only send abck cookies over https while skilled admins make sure this case in the docroot configuration independent of any script running on the host
Roundcube Users mailing list users@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/users
On 12/28/2012 11:37 PM, Noel Butler wrote:
On Fri, 2012-12-28 at 15:12 -0500, Robert Moskowitz wrote:
So your little bit would have to change the cookie content so that the browser is informed that this cookie is only to be sent over a secure connection? Only way I see to stop this behavior is for the cookie to be flagged.
<Directory "/usr/share/roundcube"> php_admin_flag session.cookie_secure "1"
<Directory>
If you use multiple virtual hosts, you dont need to put it inside a directory, you can put it in between<virtualhost> ... </virtualhost>
The few servers I have, each virtual host has its own .conf file with <virtualhost> ... </virtualhost> framework, so I don't see how I would benefit this way, just have to include this line in each that uses SSL.
which is still explaind yesterday http://php.net/manual/en/session.configuration.php#ini.session.cookie-secure
Yes, I got that and now 'getting it'. Just nit-picking, you use "1" the manual says boolean with the default of off, so just two ways of representing boolean, numeric or label. In my way of thinking (hey, I am dyslexic) labels reduce confusion because there is only off and on (no maybes) while numeric raise a question of "2"...?
This is because you are not talking directly to php, you are talking to httpd, and asking it to pass onto say mod_php, so it must be in a format that they talk to each other in.
Like If you've ever tried to manipulate error reporting you'll know you cant use "php_admin_value error_reporting E_ALL & ~E_NOTICE & ~E_DEPRECATED" - which will fail, you need to use "php_admin_value error_reporting 22519" to get the actual effect of E_ALL & ~E_NOTICE & ~E_DEPRECATED.
I was kind of noticing this, as error reporting values are 0,1,4,8 and 2
not implemented yet. Kind of looks like a switch value being passed.
At first I saw this and thought, "and what have they deprecated? (We do
this a LOT in IETF when an option value gets deprecated, like DES and
RC4, we never reuse that value) Then I said, "ah binary!"
On 12/28/2012 04:45 PM, Benny Pedersen wrote:
Robert Moskowitz skrev den 28-12-2012 21:30:
It is an interesting question, should this behaviour be default? It seems that Roundcube works from a default non-secured senario and expects those that want to secure it to know what to do.
it should be coded with secure in mind no matter how stupid webmasters is :)
Benny, please, note that I am not a coder or implementor (for the most part), I am a theory and standards guy specializing in secure communications. I have over a decade of fighting this battle (actually now close to 2 decades). From the get go, security 'just gets in the way' of people trying to get apps working. No matter how many venues we work in, our wins are small. We have pretty much been successful in lower level protocol designs, but once you get up to the session level you lose. Going through this right now with IEEE 11073 (Medical Device data modeling) and their reduced session layer. IETF's CORE is punted with DTLS.
So you webmasters/admins are stuck with the job, and esperienced ones like Harald are a blessing to have around and to learn from.
And sometimes an approach looks real good and works. Until that new app
comes around and does something that totally trashes your security.
Live with it and adapt.
please note that i did not say idiots, ups i did now :)
I suspect you can open as many tickets as you choose, the developers will most likely NOT take a secure by default posture.
hmm okay with me if both http and https is secure with the same php code, i dont think its should be a consern in end users to make sure its safe to use, if this is insecure by default i ask users to use there apple hardware :)
And I can show you lots of problems with apple hardware (software acutally). In fact, do you notice the few number of VPN products for iPads? Apple has only a few pet developers to limit where the bug reports come from; they are just not staffed for major support in bug tracing in parts of their stack. They try their best to keep developers in a nice, "safe" sandbox and staff accordingly.
The main consumer OS vendors are really trying to shut down 'fringe development' to lessen bug discovery and to make more money.
We (the security area in the IETF) have worked on this for years to get basic default security into protocol and application design. It is tilting at windmills.
there is so much problems in security that all users drop it and run unsecure to get it simple, now tcpdump kids can use there logins in stolen passwords / logins, we could start using non ssl imap/pop3/submission aswell to make it even better for all parts
Security IS hard. Much harder than Rocket Science (I know some real rocket engineers and they tell me that 'rocket science' is the easy part of their job). Dr. Noel Chiappa (author of ARP and many of the early stuff that made the Internet workable) once told me, "In an house of 100 windows, the crook only needs one open."
I have been part of work on the whole login/password challenge and a real challenge is how to implement a migration to a better world. Kind of like the IPv4/IPv6 transition that has been 10 years in the works. I really dislike any shared secret design; and I work with asymmetric designs, but we have the Certicom patents hanging over our heads (thought RFC 6090 SHOULD help here).
You want to see a very good alternative to a hashed password challenge, look at SAE in IEEE 802.11-2012; it was part of the 11s (mesh) addendum and finally starting to show in code bases. SAE gets around the SPEKE patent and provides a zero-knowledge based approach. We need to grow this method. Dan Harkins (SAE author) has an EAP method using SAE, so it is becoming available.
But this is just securing the front door. This cookie business is like the kitchen window being wide open for cooling the apple pie over night....
You are stuck with a rough row to hoe (a very America idiom?). But hey, it will be life time employment!
On Sat, 2012-12-29 at 19:18 -0500, Robert Moskowitz wrote:
<Directory "/usr/share/roundcube"> php_admin_flag session.cookie_secure "1"
<Directory>
If you use multiple virtual hosts, you dont need to put it inside a directory, you can put it in between<virtualhost> ...
</virtualhost>
The few servers I have, each virtual host has its own .conf file with <virtualhost> ... </virtualhost> framework, so I don't see how I would benefit this way, just have to include this line in each that uses SSL.
I didn't imply anything different, if you have individual conf files per vhost (and it doesnt mater if its that way or all in one big conf file), your example places the flag inside a Directory statement, I pointed out, it doesn't need to be in the Directory statement, in the normal part of the vhost config statement is fine, in fact, it's preferred.
-
Benny Pedersen -
Benny Pedersen -
Jan M. Dziewulski -
Noel Butler -
Reindl Harald -
Robert Moskowitz -
Silverfinance Firm