Re: @Wolfssl: any plans to add "ECH (Encrypted client hello) support" and question about Roadmap

2023-06-01 Thread William Lallemand
On Thu, Jun 01, 2023 at 02:15:57PM +0200, Aleksandar Lazic wrote:
> Hi,
> 
> As we have now a shiny new LTS let's take a look into the future :-)
> 
> As the Wolfssl looks like a good future alternative for OpenSSL is there 
> any plan to add ECH (Encrypted client hello) ( 
> https://github.com/haproxy/haproxy/issues/1924 ) into Wolfssl?
> 
> Is there any Idea which feature is planed to be added by HAProxy Company 
> from the feature requests 
> https://github.com/haproxy/haproxy/labels/type%3A%20feature ?
> 
> Regards
> Alex
> 

As far as I know ECH is still a draft and was not release yet, it looks
like it was already integrated in wolfssl though:

https://www.wolfssl.com/encrypted-client-hello-ech-now-supported-wolfssl/

But since the RFC is not released yet their implementation would
probably change.

But this won't probably not be usable for HAProxy since we are using the
OpenSSL compatiblity layer.

If you want to discuss this, please continue on the haproxy github
ticket or we will again split the discussion between multiple support..

-- 
William Lallemand



@Wolfssl: any plans to add "ECH (Encrypted client hello) support" and question about Roadmap

2023-06-01 Thread Aleksandar Lazic

Hi,

As we have now a shiny new LTS let's take a look into the future :-)

As the Wolfssl looks like a good future alternative for OpenSSL is there 
any plan to add ECH (Encrypted client hello) ( 
https://github.com/haproxy/haproxy/issues/1924 ) into Wolfssl?


Is there any Idea which feature is planed to be added by HAProxy Company 
from the feature requests 
https://github.com/haproxy/haproxy/labels/type%3A%20feature ?


Regards
Alex



Re: Hello HAProxy Team! I have a question about one of your posts...

2021-09-20 Thread Vanessa Diwa
Hey there!

Hope all is well, it's me again.

I sent you an email a few days ago but never heard back. Will you be
updating your post anytime soon? Would you be open to proposals, say adding
our link as an additional resource to your post?

Here is our article for your reference:
https://www.toptal.com/kubernetes/service-mesh-comparison

Hope to hear from you soon!

Cheers,
Vanessa


-Original Message-

Hi HAProxy Team,

I reached out a few days back regarding your remarkable post. Just checking
in to see if you have received my previous email regarding your article
https://www.haproxy.com/blog/power-your-consul-service-mesh-with-haproxy/
since I haven't received any feedback.

I would love to know if you are interested in adding our article
https://www.toptal.com/kubernetes/service-mesh-comparison as a resource to
your post?

You see we are hoping you can add our article as an additional resource to
your article. I believe our article goes well together and that it will
benefit your readers to know more about the article topic. One of Toptal's
goals is to provide more helpful information about the topic to others by
connecting our articles to other expert's articles like yours :)

Also, one of the most interesting benefits for you when adding our link
would be the fact that Google loves freshly updated content and tend to
rank such articles better.  As a result, this could help increase the
ranking of your article for this topic -

   - Links are Important – Linking out to pages along the same subject
   matter will give an enormous boost to your Google rankings.
   - External links ARE good for SEO and it’s widely accepted that external
   links are one of the most important metrics for high-position ranking.
   - External links are the most important source of ranking power.
   - Valuable external links will also help to improve the authority of
   your website, by providing a viewer with references.


Looking forward to hearing from you!


Cheers,
Vanessa


-Original Message-

Hi HAProxy Team,

Vanessa from Toptal here! I promise this will be quick. I just read one of
your posts -
https://www.haproxy.com/blog/power-your-consul-service-mesh-with-haproxy/
and I was hoping that we could connect.

I totally agree when you mention that Kubernetes makes configuring a
service mesh easier tactically because you can run multiple containers
inside a single pod, which is often referred to as running sidecar
containers.

When discussing microservices architecture and containerization, one set of
production-proven tools has captured most of the attention in recent years:
the service mesh.

Would you be interested in adding this as an additional resource to your
article? It will be a great update especially to your readers that are
interested in the Kubernetes service.

Here is the link for your reference:
https://www.toptal.com/kubernetes/service-mesh-comparison

Looking forward to hearing your thoughts on this and stay safe always.

Regards,
Vanessa


Re: Hello HAProxy Team! I have a question about one of your posts...

2021-09-12 Thread Vanessa Diwa
Hi HAProxy Team,

I reached out a few days back regarding your remarkable post. Just checking
in to see if you have received my previous email regarding your article
https://www.haproxy.com/blog/power-your-consul-service-mesh-with-haproxy/
since I haven't received any feedback.

I would love to know if you are interested in adding our article
https://www.toptal.com/kubernetes/service-mesh-comparison as a resource to
your post?

You see we are hoping you can add our article as an additional resource to
your article. I believe our article goes well together and that it will
benefit your readers to know more about the article topic. One of Toptal's
goals is to provide more helpful information about the topic to others by
connecting our articles to other expert's articles like yours :)

Also, one of the most interesting benefits for you when adding our link
would be the fact that Google loves freshly updated content and tend to
rank such articles better.  As a result, this could help increase the
ranking of your article for this topic -

   - Links are Important – Linking out to pages along the same subject
   matter will give an enormous boost to your Google rankings.
   - External links ARE good for SEO and it’s widely accepted that external
   links are one of the most important metrics for high-position ranking.
   - External links are the most important source of ranking power.
   - Valuable external links will also help to improve the authority of
   your website, by providing a viewer with references.


Looking forward to hearing from you!


Cheers,
Vanessa


-Original Message-

Hi HAProxy Team,

Vanessa from Toptal here! I promise this will be quick. I just read one of
your posts -
https://www.haproxy.com/blog/power-your-consul-service-mesh-with-haproxy/
and I was hoping that we could connect.

I totally agree when you mention that Kubernetes makes configuring a
service mesh easier tactically because you can run multiple containers
inside a single pod, which is often referred to as running sidecar
containers.

When discussing microservices architecture and containerization, one set of
production-proven tools has captured most of the attention in recent years:
the service mesh.

Would you be interested in adding this as an additional resource to your
article? It will be a great update especially to your readers that are
interested in the Kubernetes service.

Here is the link for your reference:
https://www.toptal.com/kubernetes/service-mesh-comparison

Looking forward to hearing your thoughts on this and stay safe always.

Regards,
Vanessa


Hello HAProxy Team! I have a question about one of your posts...

2021-09-08 Thread Vanessa Diwa
Hi HAProxy Team,

Vanessa from Toptal here! I promise this will be quick. I just read one of
your posts -
https://www.haproxy.com/blog/power-your-consul-service-mesh-with-haproxy/
and I was hoping that we could connect.

I totally agree when you mention that Kubernetes makes configuring a
service mesh easier tactically because you can run multiple containers
inside a single pod, which is often referred to as running sidecar
containers.

When discussing microservices architecture and containerization, one set of
production-proven tools has captured most of the attention in recent years:
the service mesh.

Would you be interested in adding this as an additional resource to your
article? It will be a great update especially to your readers that are
interested in the Kubernetes service.

Here is the link for your reference:
https://www.toptal.com/kubernetes/service-mesh-comparison

Looking forward to hearing your thoughts on this and stay safe always.

Regards,
Vanessa


Re: Hello ! May I ask you one question ?

2020-08-11 Thread Axel DUMAS

Hi !

Thanks to your help, my problem seem to be solved.
https://code-examples.net/en/q/16962c
http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/

You were right.
The problem of disconnections after some wait time was due to some 
timeouts parameters.


In the "default" section, there was :

   timeout connect 5000
   timeout client  5
   timeout server  5

I have replaced the values of "timeout client" and "timeout server" :

   timeout client  30m
   timeout server  30m

Thus, as my IoT devices send data every 15 minutes maximum, a timeout of 
30 minutes should be good. No ?


Also, I have added a "KeepAlive" option on the client socket (in my java 
program).


I would like to thanks you all for your help.

I will continue to learn more about HAProxy.

Sincerely,
Axel DUMAS.

PS : For futures questions, I will take care to give you more 
information. ^^
PS 2 : If you have any additional comments to make, I am always okay to 
take them. :)




Re: Hello ! May I ask you one question ?

2020-08-11 Thread Axel DUMAS

Hello !

Sorry for the subject of my email.
Sometimes, I have some understanding concern in English.

So you want all the configuration of HAProxy ? You can look at the 
attachment (haproxy.cfg). I have just used the basic configuration of 
HAProxy.
And I have forgotten to mention the version of HAProxy (maybe there are 
some differences) : HA-Proxy version 1.8.19-1+deb10u2 2020/04/01.


Also, sorry for the asterisks they seems to be added after my sending. :/

You can see the logs after a restart and some exchange of data.
I have seen that when I change the configuration of my IoT device to a 
sending interval of 30 seconds instead of 15 minutes or 30 minutes, 
HAProxy works and exchanges between my device and my java server seems 
to be made normally. So maybe, it's a problem of timeout.



Also, you can see in the log file, these two last lines :

   Aug 11 11:24:30 AS-Freedom haproxy[5371]: 185.99.26.70:60749
   [11/Aug/2020:11:22:12.639] srv_java all_java_srv/srv_1 1/0/138128 17
   cD 1/1/0/0/0 0/0
   Aug 11 11:27:36 AS-Freedom haproxy[5371]: 185.99.26.66:49655
   [11/Aug/2020:11:26:45.595] srv_java all_java_srv/srv_1 1/0/50755 5
   cD 1/1/0/0/0 0/0

I think they should be appearing when the connection is interrupted 
between the server and the device is interrupted.


I will search again about timeouts in HAProxy.

Thanks a lot for your help !
And sorry for the lack of information.
Sincerely.


Le 11/08/2020 à 00:00, Tim Düsterhus a écrit :

Axel,

Am 10.08.20 um 19:02 schrieb Axel DUMAS:

Can I ask my question here ? Or do I have to write it in an other place ?

This is the appropriate place. However I must admit that your email
looked like spam based off the Subject at a first glance.


In order to test load-balancing, in the config file of HAProxy, I wrote
theses two things :
*frontend* java_srv
*bind* 192.168.0.19:26001
*mode* tcp
*default_backend* all_java_srv

*backend* all_java_srv
*balance* roundrobin
*mode* tcp
*server* srv_1 192.168.0.19:26001

Can you please give your *literal* configuration instead of just the
options you consider important? And please give the configuration in the
original format without the asterisks in there.


Some fast exchanges seems to be made between the IoT device and my
server, but when it have to wait, the connection is cut and the device
is disconnected.

Any error messages? Did you enable logging in HAProxy (you should)? Can
you provide a log message?

Best regards
Tim Düsterhus
Aug 11 11:20:34 AS-Freedom haproxy[5188]: [WARNING] 223/111742 (5188) : Exiting Master process...
Aug 11 11:20:34 AS-Freedom haproxy[5188]: [ALERT] 223/111742 (5188) : Current worker 5189 exited with code 143
Aug 11 11:20:34 AS-Freedom haproxy[5188]: [WARNING] 223/111742 (5188) : All workers exited. Exiting... (143)
Aug 11 11:20:34 AS-Freedom haproxy[5370]: [WARNING] 223/112034 (5370) : parsing [/etc/haproxy/haproxy.cfg:26] : 'option httplog' not usable with frontend 'srv_java' (needs 'mode http'). Falling back to 'option tcplog'.
Aug 11 11:20:34 AS-Freedom haproxy[5370]: Proxy srv_java started.
Aug 11 11:20:34 AS-Freedom haproxy[5370]: Proxy srv_java started.
Aug 11 11:20:34 AS-Freedom haproxy[5370]: Proxy all_java_srv started.
Aug 11 11:20:34 AS-Freedom haproxy[5370]: Proxy all_java_srv started.
Aug 11 11:24:30 AS-Freedom haproxy[5371]: 185.99.26.70:60749 [11/Aug/2020:11:22:12.639] srv_java all_java_srv/srv_1 1/0/138128 17 cD 1/1/0/0/0 0/0
Aug 11 11:27:36 AS-Freedom haproxy[5371]: 185.99.26.66:49655 [11/Aug/2020:11:26:45.595] srv_java all_java_srv/srv_1 1/0/50755 5 cD 1/1/0/0/0 0/0


global
log /dev/loglocal0
log /dev/loglocal1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd 
listeners
stats timeout 30s
user haproxy
group haproxy
daemon

# Default SSL material locations
ca-base /etc/ssl/certs
crt-base /etc/ssl/private

# Default ciphers to use on SSL-enabled listening sockets.
# For more information, see ciphers(1SSL). This list is from:
#  https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
# An alternative list with additional directives can be obtained from
#  
https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=haproxy
ssl-default-bind-ciphers 
ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
ssl-default-bind-options no-sslv3

defaults
log global
modehttp
option  httplog
option  dontlognull
timeout connect 5000
timeout client  5
timeout server  5
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc

Re: Hello ! May I ask you one question ?

2020-08-10 Thread Tim Düsterhus
Axel,

Am 10.08.20 um 19:02 schrieb Axel DUMAS:
> Can I ask my question here ? Or do I have to write it in an other place ?

This is the appropriate place. However I must admit that your email
looked like spam based off the Subject at a first glance.

> In order to test load-balancing, in the config file of HAProxy, I wrote
> theses two things :
> *frontend* java_srv
> *bind* 192.168.0.19:26001
> *mode* tcp
> *default_backend* all_java_srv
> 
> *backend* all_java_srv
> *balance* roundrobin
> *mode* tcp
> *server* srv_1 192.168.0.19:26001

Can you please give your *literal* configuration instead of just the
options you consider important? And please give the configuration in the
original format without the asterisks in there.

> Some fast exchanges seems to be made between the IoT device and my
> server, but when it have to wait, the connection is cut and the device
> is disconnected.

Any error messages? Did you enable logging in HAProxy (you should)? Can
you provide a log message?

Best regards
Tim Düsterhus



Hello ! May I ask you one question ?

2020-08-10 Thread Axel DUMAS

Hello !
I am a new (french) user of HAProxy. I have learned some little things 
on it and on the configuration file and parameters.


I wanted to use/learn it for my project, but I have some problems that I 
don't know how to solve.

I have made some searchs...but I haven't found a corresponding answer.

I would like to use HAProxy for load-balancing on my custom TCP Java Server.
It's for the IoT domain.

Can I ask my question here ? Or do I have to write it in an other place ?


I will try to explain you how does it works. Actually, the IoT device 
connect to my server and open a "link" with it. In addition, it create 
one thread per connection.

My server will keep this link open and answer to the IoT device.
The device will use this link in order to send futures data to my 
server. So the link between the device and the server can be opened 
during many hours.

I am not an expert so...I expect you will understand.

In order to test load-balancing, in the config file of HAProxy, I wrote 
theses two things :

*frontend* java_srv
*bind* 192.168.0.19:26001
*mode* tcp
*default_backend* all_java_srv

*backend* all_java_srv
*balance* roundrobin
*mode* tcp
*server* srv_1 192.168.0.19:26001

Some fast exchanges seems to be made between the IoT device and my 
server, but when it have to wait, the connection is cut and the device 
is disconnected.


Do you have an idea of what could be wrong with my configuration file ? 
Or could you give me one suggestion ?

Also, yes, I have only one server for the moment.

If you have any question, feel free to ask.
I thanks you a lot for your help.

And in case that this email is not made for asking question, I am sorry 
for that.

Have a good evening,
Sincerely.



Hello

2019-08-31 Thread Linda Miller
Who designed your website "formilux.org"???



Regards,

Linda


Hello

2019-08-21 Thread Victoria Sandoval
Have you removed push notification from your website www.formilux.org

Regards,
Victoria


Re: SPOE and modsecurity contrib Failed to decode HELLO frame

2018-08-17 Thread Aleksandar Lazic
Hi.

Am 16.08.2018 um 11:00 schrieb Павел.:
> 
> HI all! I'm compile modsec as described in the instructions
> contib/modsec/README, but have the next errors:

Which version of haproxy and this contib do you use?
There was some changes recently.

http://www.haproxy.org/download/1.8/src/CHANGELOG
2018/06/22 : 1.8.10

Regards
Aleks

> # /usr/local/bin/modsecurity -n 4 -d -f /etc/haproxy/waf/modsecurity.conf
> 1534409877.286475 [00] ModSecurity for nginx (STABLE)/2.9.2
> (http://www.modsecurity.org/) configured.
> 1534409877.286555 [00] ModSecurity: APR compiled version="1.4.8"; loaded
> version="1.4.8"
> 1534409877.286577 [00] ModSecurity: PCRE compiled version="8.32 "; loaded
> version="8.32 2012-11-30"
> 1534409877.286593 [00] ModSecurity: YAJL compiled version="2.0.4"
> 1534409877.286610 [00] ModSecurity: LIBXML compiled version="2.9.1"
> 1534409877.286723 [00] ModSecurity: StatusEngine call:
> "2.9.2,nginx,1.4.8/1.4.8,8.32/8.32
> 2012-11-30,(null),2.9.1,4c3b0f175f079eaa4dd15b6eaef7a8207e809bb8"
> 1534409877.494433 [00] ModSecurity: StatusEngine call successfully sent. For
> more information visit: http://status.modsecurity.org/
> 1534409877.495333 [00] Worker 01 initialized
> 1534409877.495453 [01] Worker ready to process client messages
> 1534409877.495499 [00] Worker 02 initialized
> 1534409877.495514 [02] Worker ready to process client messages
> 1534409877.495767 [00] Worker 03 initialized
> 1534409877.495817 [03] Worker ready to process client messages
> 1534409877.495925 [00] Worker 04 initialized
> 1534409877.495958 [00] Server is ready [fragmentation=false - 
> pipelining=false -
> async=false - debug=true - max-frame-size=16384]
> 1534409877.495961 [04] Worker ready to process client messages
> 1534409881.192419 [00] <1> New Client connection accepted and assigned to 
> worker 01
> 1534409881.192511 [01] <1> read_frame_cb
> 1534409881.192596 [01] <1> New Frame of 129 bytes received
> 1534409881.192606 [01] <1> Decode HAProxy HELLO frame
> 1534409881.192613 [01] Failed to decode HELLO frame
> 1534409881.192617 [01] <1> Encode Agent DISCONNECT frame
> 1534409881.192626 [01] <1> Disconnect status code : 10
> 1534409881.192630 [01] <1> Disconnect message : fragmentation not supported
> 1534409881.192648 [01] <1> write_frame_cb
> 1534409881.192689 [01] <1> Frame of 58 bytes send
> 1534409881.192695 [01] <1> Release client
> 1534409882.497134 [01] 0 clients connected
> 1534409882.497174 [02] 0 clients connected
> 1534409882.497197 [04] 0 clients connected
> 1534409882.497185 [03] 0 clients connected
> ^C1534409885.480782 [00] Stopping the server
> 
> Has anyone encountered a similar one?
> 
> -- 
> Павел.




SPOE and modsecurity contrib Failed to decode HELLO frame

2018-08-16 Thread Павел .

HI all! I'm compile modsec  as described in the instructions 
contib/modsec/README, but have the next errors:

# /usr/local/bin/modsecurity -n 4 -d -f /etc/haproxy/waf/modsecurity.conf
1534409877.286475 [00] ModSecurity for nginx (STABLE)/2.9.2 
(http://www.modsecurity.org/) configured.
1534409877.286555 [00] ModSecurity: APR compiled version="1.4.8"; loaded 
version="1.4.8"
1534409877.286577 [00] ModSecurity: PCRE compiled version="8.32 "; loaded 
version="8.32 2012-11-30"
1534409877.286593 [00] ModSecurity: YAJL compiled version="2.0.4"
1534409877.286610 [00] ModSecurity: LIBXML compiled version="2.9.1"
1534409877.286723 [00] ModSecurity: StatusEngine call: 
"2.9.2,nginx,1.4.8/1.4.8,8.32/8.32 
2012-11-30,(null),2.9.1,4c3b0f175f079eaa4dd15b6eaef7a8207e809bb8"
1534409877.494433 [00] ModSecurity: StatusEngine call successfully sent. For 
more information visit: http://status.modsecurity.org/
1534409877.495333 [00] Worker 01 initialized
1534409877.495453 [01] Worker ready to process client messages
1534409877.495499 [00] Worker 02 initialized
1534409877.495514 [02] Worker ready to process client messages
1534409877.495767 [00] Worker 03 initialized
1534409877.495817 [03] Worker ready to process client messages
1534409877.495925 [00] Worker 04 initialized
1534409877.495958 [00] Server is ready [fragmentation=false - pipelining=false 
- async=false - debug=true - max-frame-size=16384]
1534409877.495961 [04] Worker ready to process client messages
1534409881.192419 [00] <1> New Client connection accepted and assigned to 
worker 01
1534409881.192511 [01] <1> read_frame_cb
1534409881.192596 [01] <1> New Frame of 129 bytes received
1534409881.192606 [01] <1> Decode HAProxy HELLO frame
1534409881.192613 [01] Failed to decode HELLO frame
1534409881.192617 [01] <1> Encode Agent DISCONNECT frame
1534409881.192626 [01] <1> Disconnect status code : 10
1534409881.192630 [01] <1> Disconnect message : fragmentation not supported
1534409881.192648 [01] <1> write_frame_cb
1534409881.192689 [01] <1> Frame of 58 bytes send
1534409881.192695 [01] <1> Release client
1534409882.497134 [01] 0 clients connected
1534409882.497174 [02] 0 clients connected
1534409882.497197 [04] 0 clients connected
1534409882.497185 [03] 0 clients connected
^C1534409885.480782 [00] Stopping the server

Has anyone encountered a similar one?

-- 
Павел.

Hello, I have a question about a post on feedjunkie.com

2018-02-07 Thread Anna Kucirkova
Hello there

Your page http://feedjunkie.com/item/26333552/Where Athletes In The Worlds Top 
Sports Leagues Come F has some good references to some of the best athletes in 
the world so I wanted to get in touch with you. I've recently written an 
article about Roger Federer and was wondering if you thought my article could 
help out on your page.

You can read all the information right here:  
https://tennisdrills.tv/5-skills-set-roger-federer-apart-rest/

It would be great to know your opinion on the article. And if you find it 
useful please consider linking to it from that page of yours. Also if you 
prefer you may republish the article. How does that sound to you?.

Thank you very much,

Anna.



hello

2017-12-26 Thread missthe...@gmail.com
subscribe



==
孙涛
+86 18516526973
missthe...@gmail.com
==


Hello

2016-08-26 Thread Jepdrp1

Hello, I am receiving a pop up states from Microsoft edge and HA Proxy 
statistics asking for my sign in. Is this you?  what is this for? And how do I 
eliminate it?
Thank You,
James E Poirier


Hello, our company is specializing in the production of LEDT5 / T8 fluorescent lamp, ball bubble lamp, tube lamp, project-light lamp, mining lamp, etc...

2016-08-15 Thread 江丘朝
Dear purchasing manager,
Hello, beautiful bright lighting lighting co., LTD., our company is a 
professional manufacturer of LED lighting, we want to provide high quality 
products and competitive price, hope to be a partner of your company.
If you want to know more about our products, free samples.
Thank you in advance!
The best blessing
Contact phone number;13549869197
18928105697, Mr Jiang
QQ, 3037277174





Address;China guangdong zhongshan guzhen haizhou industrial zone.9

[SPAM] hello!

2015-05-05 Thread Natalia
hello!

how are you today? What is your name?
my name is Natalia, You frequently are on this site?
I today wanted to talk to you in a chat, but you have already left a chat, 
Ithink that in the near future we with you shall talk, how you consider?
You have yahoo or hotmail ID? if you write to me, ok?
I shall wait from you the letter with impatience

My email kalabukhina@yandex.ru mailto:kalabukhina@yandex.ru

Natalia

[SPAM] Hello haproxy

2015-03-09 Thread Concetta
Hello) My name is Olga. Ilive in Moscow.

I found out your page onthe Internet and I was curious about you.
Tell me, please, what are you doing now and how do you spend your life 
ingeneral?

In fact, you're interesting to me as a personality, and Iwant to communicate 
with you http://tuzlaelektrik.com/backup.html in the future.

Re: Mix option httpchk and ssl-hello-chk

2014-10-02 Thread Willy Tarreau
On Fri, Sep 26, 2014 at 04:37:17PM +0200, Kevin COUSIN wrote:
 Here is my conf :
 
 backend bk_OWAP-SSL
 timeout server  30s
 timeout connect 5s
 mode http
 balance roundrobin
 
 option forwardfor
 #option ssl-hello-chk
 option httplog
 #option httpchk
 #hash-type consistent
 
 server PP-OWAP01001 172.21.13.79:443 ssl weight 1 check 
 verify none
 
 
 I just want to check the HTTP response (200 OK or 302) of the backend 
 server.

So that's simple, just remove option ssl-hello-chk and enable
option httpchk instead. It will enable HTTP checks to your server,
and since your server is declared with ssl, the check will be done
over SSL.

Regards,
Willy




Re: Mix option httpchk and ssl-hello-chk

2014-09-26 Thread Kevin COUSIN


Le 22/09/2014 15:44, Baptiste a écrit :

On Mon, Sep 22, 2014 at 3:33 PM, Kevin COUSIN ki...@kiven.fr wrote:

Hi list,

Can I mix the option httpchk and ssl-hello-chk to check the health of an HTTPS 
website ?

Thanks a lot



Kevin C.


Hi Kevin,

No, you can't.

It would be easier to answer you with your backend configuration!
That said, you can have a look at the check-ssl option, which may help.

Baptiste


Hi Baptiste,

Here is my conf :

backend bk_OWAP-SSL
timeout server  30s
timeout connect 5s
mode http
balance roundrobin

option forwardfor
#option ssl-hello-chk
option httplog
#option httpchk
#hash-type consistent

server PP-OWAP01001 172.21.13.79:443 ssl weight 1 check 
verify none



I just want to check the HTTP response (200 OK or 302) of the backend 
server.


Regards,

Kevin C



Mix option httpchk and ssl-hello-chk

2014-09-22 Thread Kevin COUSIN
Hi list, 

Can I mix the option httpchk and ssl-hello-chk to check the health of an HTTPS 
website ?

Thanks a lot



   Kevin C.



Re: Mix option httpchk and ssl-hello-chk

2014-09-22 Thread Baptiste
On Mon, Sep 22, 2014 at 3:33 PM, Kevin COUSIN ki...@kiven.fr wrote:
 Hi list,

 Can I mix the option httpchk and ssl-hello-chk to check the health of an 
 HTTPS website ?

 Thanks a lot

 

Kevin C.


Hi Kevin,

No, you can't.

It would be easier to answer you with your backend configuration!
That said, you can have a look at the check-ssl option, which may help.

Baptiste



HELLO

2014-04-26 Thread kish patrick
Friend.
 
I decided to share this lucrative opportunity with you, I am the foreign 
operations manager of our bank here in my country, Burkina Faso West Africa. i 
am married with four children. I want you to assist me in other to transfer the 
sum of into your reliable account as the business partner to our Foreign 
Business partner,Since the deceased left no body behind to claim the fund, as a 
foreigner, you are in better position for that, and nobody will come for the 
claim after you have applied. If you are ready to assist me, set up a new bank 
account or forward to me any one available so that the process will commence. I 
will guide you on how you should apply for the claim so that everything will be 
smooth and correct. After the transfer, i will resign and come over to your 
country for the sharing of the fund 50/50 base on the fact that it is two man 
businesses. 
 
Finally, note that you are not taking any risk because there will be a legal 
back up as we commence. Further information will be given to you as soon as I 
receive your reply.
 
Your friend.
 




RE: Query regarding extracting ssl hello sni.

2014-04-11 Thread Lukas Tribus
Hi,


 I would suggest that it will not harm even if you relax the check for
 client hello too as the old client can using SSL 3.0 is still supported
 and its according to RFC

I disagree. SNI is documented as a TLS extension and unsupported in SSLv3.
RFC3546 and RFC6066 are the relevant RFCs, not RFC5246.

Try SSLv3 with SNI:
 openssl s_client -connect localhost:443 -servername snitest -ssl3

The client_hello doesn't contain SNI, because TLS extensions are not
supported in SSLv3.



 and also note that the max supported TLS version is 3.3. I would suggest
 the below mentioned changes.

I disagree here also. Why should we limit the max supported TLS version and
introduce forward compatibility issues? We will just be a like those stupid
obsolete SSL middleboxes the browsers need to workaround everytime they
enable a new SSL feature. I would rather avoid that.



Regards,

Lukas

  


Re: Query regarding extracting ssl hello sni.

2014-04-11 Thread Pravin Tatti
I too agree with your first comment relax only the check for record layer
version as SNI is extensions for TLS protocols.
I think the next version may or may not contain the same client hello
format if it allows i don't have any issues if it doesn't allows then the
code may crash or it may return bad value for SNI. I just suggested it for
safety reasons its just my input.


On Fri, Apr 11, 2014 at 12:09 PM, Lukas Tribus luky...@hotmail.com wrote:

 Hi,


  I would suggest that it will not harm even if you relax the check for
  client hello too as the old client can using SSL 3.0 is still supported
  and its according to RFC

 I disagree. SNI is documented as a TLS extension and unsupported in SSLv3.
 RFC3546 and RFC6066 are the relevant RFCs, not RFC5246.

 Try SSLv3 with SNI:
  openssl s_client -connect localhost:443 -servername snitest -ssl3

 The client_hello doesn't contain SNI, because TLS extensions are not
 supported in SSLv3.



  and also note that the max supported TLS version is 3.3. I would suggest
  the below mentioned changes.

 I disagree here also. Why should we limit the max supported TLS version and
 introduce forward compatibility issues? We will just be a like those stupid
 obsolete SSL middleboxes the browsers need to workaround everytime they
 enable a new SSL feature. I would rather avoid that.



 Regards,

 Lukas




RE: Query regarding extracting ssl hello sni.

2014-04-11 Thread Lukas Tribus
Hi,


 I think the next version may or may not contain the same client hello 
 format if it allows i don't have any issues if it doesn't allows then 
 the code may crash or it may return bad value for SNI. I just suggested 
 it for safety reasons its just my input.

If HAproxy would crash, we would need to fix the actual reason of the
crash, not ignore SNI when TLS version is higher than 1.2, because an
attacker can always send packets with TLSv1.2 and the offending payload,
even if its not valid packet as per RFC.


As for bad values: SNI is a client provided value and thus must never
be trusted. We can use it for routing the request to different backends,
but we always need to validate it before doing something with it.




Regards,

Lukas

  


Re: Query regarding extracting ssl hello sni.

2014-04-11 Thread Pravin Tatti
Ok fine you can be forward compatible but i still don't agree its my
personal opinion if I don't know what the packet format for next version
why should I support it. But this was not the major issue for what i
started the discussion. I think the major is relaxing the record layer
check to SSLv3 and we should fix it.




On Fri, Apr 11, 2014 at 4:32 PM, Lukas Tribus luky...@hotmail.com wrote:

 Hi,


  I think the next version may or may not contain the same client hello
  format if it allows i don't have any issues if it doesn't allows then
  the code may crash or it may return bad value for SNI. I just suggested
  it for safety reasons its just my input.

 If HAproxy would crash, we would need to fix the actual reason of the
 crash, not ignore SNI when TLS version is higher than 1.2, because an
 attacker can always send packets with TLSv1.2 and the offending payload,
 even if its not valid packet as per RFC.


 As for bad values: SNI is a client provided value and thus must never
 be trusted. We can use it for routing the request to different backends,
 but we always need to validate it before doing something with it.




 Regards,

 Lukas




Re: Query regarding extracting ssl hello sni.

2014-04-11 Thread Willy Tarreau
On Fri, Apr 11, 2014 at 04:57:17PM +0530, Pravin Tatti wrote:
 Ok fine you can be forward compatible but i still don't agree its my
 personal opinion if I don't know what the packet format for next version
 why should I support it. But this was not the major issue for what i
 started the discussion. I think the major is relaxing the record layer
 check to SSLv3 and we should fix it.

It's not a matter of opinion but specification. If the packet format is
specified as being exclusively for 3.0..3.3, then we should only match
this. If it's specified as part of TLS for which only versions 3.0 to
3.3 are currently defined, then we must apply the default rule specified
for the whole protocol according to how to handle newer versions. All
protocols generally indicate how newer versions must be handled, and
it's important to stick on the rule they dictate in order not to break
interoperability with future clients.

Willy




RE: Query regarding extracting ssl hello sni.

2014-04-11 Thread Lukas Tribus
Hi,


 Ok fine you can be forward compatible but i still don't agree its my 
 personal opinion if I don't know what the packet format for next 
 version why should I support it.

Because we are talking about a industry standard with a huge user base
and it is very likely that next version will be backwards compatible,
like it was the case with TLSv1.2-TLSv1.1-TLSv1.0-SSLv3. Its unlikely
that the IETF WG will push a change that will break this format.

If the next TLS version doesn't break it, SNI will continue to work.
If the next TLS version breaks SNI, we will need to fix it.

If we restrict the SNI fetching to TLSv1.[0-2], we need to fix SNI
in every case, without any obvious advantage.



 I think the major is relaxing the record layer check to SSLv3 and we
 should fix it. 

Its already fixed, Willy committed it yesterday. Tonight's snapshot already
contains the fix.




Regards,

Lukas

  


RE: Query regarding extracting ssl hello sni.

2014-04-11 Thread Lukas Tribus
Hi,


 It's not a matter of opinion but specification. If the packet format is
 specified as being exclusively for 3.0..3.3, then we should only match
 this. If it's specified as part of TLS for which only versions 3.0 to
 3.3 are currently defined, then we must apply the default rule specified
 for the whole protocol according to how to handle newer versions. All
 protocols generally indicate how newer versions must be handled, and
 it's important to stick on the rule they dictate in order not to break
 interoperability with future clients.

Mmmmh, good point.


TLS extensions are documented pretty strictly against certain TLS version:
RFC3546 -- TLSv1.0
RFC4366 -- TLSv1.0 and TLSv1.1
RFC6066 -- TLSv1.2


I'm not sure that those RFCs really address forward compatibility. I took
a very quick look at RFC6066, but didn't found any real indication of what
will happen in future version, other than:

   Currently, the only server names supported are DNS hostnames;
   however, this does not imply any dependency of TLS on DNS, and other
   name types may be added in the future (by an RFC that updates this
   document).  The data structure associated with the host_name NameType
   is a variable-length vector that begins with a 16-bit length.  For
   backward compatibility, all future data structures associated with
   new NameTypes MUST begin with a 16-bit length field.  TLS MAY treat
   provided server names as opaque data and pass the names and types to
   the application.


So, according to what you said and how the RFCs are written Pravin would
be right suggesting to limit the SNI fetch to TLSv1.2.

Anyway, even if we do this, its a good thing to separate the bugfix (relax
the record version check) and a change (only fetch SNI up to TLSv1.2) instead
of having both in a single commit.


So, should we do this? Should both record version and client_hello be checked
to be = TLSv1.2?




Regards,

Lukas

  


Re: Query regarding extracting ssl hello sni.

2014-04-11 Thread Willy Tarreau
Hi Lukas,

On Fri, Apr 11, 2014 at 03:17:32PM +0200, Lukas Tribus wrote:
 Hi,
 
  It's not a matter of opinion but specification. If the packet format is
  specified as being exclusively for 3.0..3.3, then we should only match
  this. If it's specified as part of TLS for which only versions 3.0 to
  3.3 are currently defined, then we must apply the default rule specified
  for the whole protocol according to how to handle newer versions. All
  protocols generally indicate how newer versions must be handled, and
  it's important to stick on the rule they dictate in order not to break
  interoperability with future clients.
 
 Mmmmh, good point.
 
 
 TLS extensions are documented pretty strictly against certain TLS version:
 RFC3546 -- TLSv1.0
 RFC4366 -- TLSv1.0 and TLSv1.1
 RFC6066 -- TLSv1.2

 I'm not sure that those RFCs really address forward compatibility.

Well, I have a different interpretation of this. First, 2246 clearly says
that TLSv1.0 has major 3 and minor 1 because it's a minor improvement over
SSLv3.0. So that clearly states that a change of the minor here only means
a minor improvement.

Second, 3546 discusses extensions and says :

  The extensions may be used by TLS clients and servers.  The
   extensions are backwards compatible - communication is possible
   between TLS 1.0 clients that support the extensions and TLS 1.0
   servers that do not support the extensions, and vice versa.

This implies forward compatibility since both sides may use extensions
in a backwards compatible way with the other one. Otherwise, lack of
forward compatibility would break this type of backwards compatibility.

5246 says this :

  Appendix E.  Backward Compatibility

   E.1.  Compatibility with TLS 1.0/1.1 and SSL 3.0

   Since there are various versions of TLS (1.0, 1.1, 1.2, and any
   future versions) and SSL (2.0 and 3.0), means are needed to negotiate
   the specific protocol version to use.  The TLS protocol provides a
   built-in mechanism for version negotiation so as not to bother other
   protocol components with the complexities of version selection.

   TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use
   compatible ClientHello messages; thus, supporting all of them is
   relatively easy.  Similarly, servers can easily handle clients trying
   to use future versions of TLS as long as the ClientHello format
   remains compatible, and the client supports the highest protocol
   version available in the server.

   A TLS 1.2 client who wishes to negotiate with such older servers will
   send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
   ClientHello.client_version.  If the server does not support this
   version, it will respond with a ServerHello containing an older
   version number.  If the client agrees to use this version, the
   negotiation will proceed as appropriate for the negotiated protocol.

Again, to me it clearly states that the focus is on supporting different
versions on both sides, which implies that a client talking 1.2 can be
understood by a server talking 1.1 etc...

I see nothing in these specs mandating a limit to a certain protocol
level for certain features. All I'm seeing is protocol version is
{ 3, 3 } for this version of the spec in 1.2, or { 3, 2 } for 1.1,
etc... It just reminds what to *emit* to indicate what protocol you're
speaking, not anything related to a sudden drop of forwards compatibility.

So in my opinion, since the protocol is designed to be backwards and
forwards compatible, and uses minor version for newer extensions, there
is no reason for limiting ourselves to TLSv1.2 for extensions that
exist since 1.0 and will certainly continue to be supported by later
version, at least for backwards compatibility.

Regards,
Willy




RE: Query regarding extracting ssl hello sni.

2014-04-11 Thread Lukas Tribus
Hi Willy,


 So in my opinion, since the protocol is designed to be backwards and
 forwards compatible, and uses minor version for newer extensions, there
 is no reason for limiting ourselves to TLSv1.2 for extensions that
 exist since 1.0 and will certainly continue to be supported by later
 version, at least for backwards compatibility.

Ok. I do in fact agree with this and it matches with what I was saying
earlier in this thread, I just didn't take the time to read the RFC
carefully enough to draw the same conclusion.



Thanks,

Lukas

  


Re: Query regarding extracting ssl hello sni.

2014-04-10 Thread Willy Tarreau
Hi,

On Thu, Apr 10, 2014 at 10:33:38AM +0530, Pravin Tatti wrote:
 Hi,
 
 The function smp_fetch_ssl_hello_sni() only supports record layer version
 and client hello version greater than or equal to 3.1. But as in the
 RFC5246 in appendix E says that TLS versions 1.0, 1.1, and 1.2, and SSL
 3.0 are very similar and also if we check the last 2 paras as mentioned
 below
 
  Earlier versions of the TLS specification were not fully clear on what
 the record layer version number (TLSPlaintext.version) should contain when
 sending ClientHello (i.e., before it is known which version of the protocol
 will be employed). Thus, TLS servers compliant with this specification MUST
 accept any value {03,XX} as the record layer version number for
 ClientHello.
 
 TLS clients that wish to negotiate with older servers MAY send any value
 {03,XX} as the record layer version number. Typical values would be
 {03,00}, the lowest version number supported by the client, and the value
 of ClientHello.client_version. No single value will guarantee
 interoperability with all old servers, but this is a complex topic beyond
 the scope of this document. 
 
 This indicates that the tls record version might be SSL 3.0 and the client
 hello might be TLS version 1.0, 1.1 or 1.2.
 
 Do we need to consider this case while parsing in smp_fetch_ssl_hello_sni()
 or is there any other specific reason for it.
 
 I noticed such kind of issue when application is using gnutls instead of
 openssl.
 ie., the record layer version is SSL 3.0 and client hello is 3.3.

Well, there is no particular reason for being limited to a certain set of
versions, however I think we did it this way because SNI started to be used
long after any client totally stopped supporting SSLv3, so it did not appear
that there was any intersection between SSLv3 and SNI. But if there is, sure,
maybe propose a patch!

Thanks,
Willy




Re: Query regarding extracting ssl hello sni.

2014-04-10 Thread Pravin Tatti
I think you still didn't understood the problem. There are two versions in
SSL one is record layer hello version and the client hello version. Any
application that support TLS versions 1.0, 1.1, 1.3 or SSLv3 (client hello
version) may contain SSL 3.0 as the record layer version number and the
once the negotiation is done the record layer version is updated.
The problem is not with SSLv3 alone the problem is with all the TLS
versions 1.0, 1.1, 1.3 or SSLv3 who has the record layer version as SSLv3
for client hello packet.

The problem is the application using gnutls instead of openssl has record
layer hello version set to SSL 3.0 for client hello handshake and the
client hello version to TLSv2 (max TLS version supported by client).

What i suggest is fetching of SNI is still valid even if the record layer
version is 3.0 and the actual client hello version is any of the TLS
versions including SSLv3.




On Thu, Apr 10, 2014 at 2:34 PM, Willy Tarreau w...@1wt.eu wrote:

  [image: Boxbe] https://www.boxbe.com/overview Willy Tarreau (w...@1wt.eu)
 is not on your Guest 
 Listhttps://www.boxbe.com/approved-list?tc_serial=16879868868tc_rand=1178275786utm_source=stfutm_medium=emailutm_campaign=ANNO_MWTPutm_content=001token=%2Fwy11T7R1QVKnkycPjMukAJgXwKDuCjUkkpoPo3fnUbD27SXBkGi8peGgEmh%2FReckey=pl7vWF6XC3JfowFZA%2F0CL7u6ZiLZzX%2BJ6UJhky1jiZM%3D|
  Approve
 senderhttps://www.boxbe.com/anno?tc_serial=16879868868tc_rand=1178275786utm_source=stfutm_medium=emailutm_campaign=ANNO_MWTPutm_content=001token=%2Fwy11T7R1QVKnkycPjMukAJgXwKDuCjUkkpoPo3fnUbD27SXBkGi8peGgEmh%2FReckey=pl7vWF6XC3JfowFZA%2F0CL7u6ZiLZzX%2BJ6UJhky1jiZM%3D|
  Approve
 domainhttps://www.boxbe.com/anno?tc_serial=16879868868tc_rand=1178275786utm_source=stfutm_medium=emailutm_campaign=ANNO_MWTPutm_content=001domtoken=%2Fwy11T7R1QVKnkycPjMukAJgXwKDuCjUkkpoPo3fnUbD27SXBkGi8peGgEmh%2FReckey=pl7vWF6XC3JfowFZA%2F0CL7u6ZiLZzX%2BJ6UJhky1jiZM%3D

 Hi,

 On Thu, Apr 10, 2014 at 10:33:38AM +0530, Pravin Tatti wrote:
  Hi,
 
  The function smp_fetch_ssl_hello_sni() only supports record layer version
  and client hello version greater than or equal to 3.1. But as in the
  RFC5246 in appendix E says that TLS versions 1.0, 1.1, and 1.2, and SSL
  3.0 are very similar and also if we check the last 2 paras as mentioned
  below
 
   Earlier versions of the TLS specification were not fully clear on what
  the record layer version number (TLSPlaintext.version) should contain
 when
  sending ClientHello (i.e., before it is known which version of the
 protocol
  will be employed). Thus, TLS servers compliant with this specification
 MUST
  accept any value {03,XX} as the record layer version number for
  ClientHello.
 
  TLS clients that wish to negotiate with older servers MAY send any value
  {03,XX} as the record layer version number. Typical values would be
  {03,00}, the lowest version number supported by the client, and the value
  of ClientHello.client_version. No single value will guarantee
  interoperability with all old servers, but this is a complex topic beyond
  the scope of this document. 
 
  This indicates that the tls record version might be SSL 3.0 and the
 client
  hello might be TLS version 1.0, 1.1 or 1.2.
 
  Do we need to consider this case while parsing in
 smp_fetch_ssl_hello_sni()
  or is there any other specific reason for it.
 
  I noticed such kind of issue when application is using gnutls instead of
  openssl.
  ie., the record layer version is SSL 3.0 and client hello is 3.3.

 Well, there is no particular reason for being limited to a certain set of
 versions, however I think we did it this way because SNI started to be used
 long after any client totally stopped supporting SSLv3, so it did not
 appear
 that there was any intersection between SSLv3 and SNI. But if there is,
 sure,
 maybe propose a patch!

 Thanks,
 Willy





Re: Query regarding extracting ssl hello sni.

2014-04-10 Thread Willy Tarreau
On Thu, Apr 10, 2014 at 06:30:26PM +0530, Pravin Tatti wrote:
 I think you still didn't understood the problem. There are two versions in
 SSL one is record layer hello version and the client hello version. Any
 application that support TLS versions 1.0, 1.1, 1.3 or SSLv3 (client hello
 version) may contain SSL 3.0 as the record layer version number and the
 once the negotiation is done the record layer version is updated.
 The problem is not with SSLv3 alone the problem is with all the TLS
 versions 1.0, 1.1, 1.3 or SSLv3 who has the record layer version as SSLv3
 for client hello packet.

OK thanks for clarifying.

 The problem is the application using gnutls instead of openssl has record
 layer hello version set to SSL 3.0 for client hello handshake and the
 client hello version to TLSv2 (max TLS version supported by client).
 
 What i suggest is fetching of SNI is still valid even if the record layer
 version is 3.0 and the actual client hello version is any of the TLS
 versions including SSLv3.

Fine, could you send a patch to do that then ?

Willy




RE: Query regarding extracting ssl hello sni.

2014-04-10 Thread Lukas Tribus



 Date: Thu, 10 Apr 2014 15:22:43 +0200
 From: w...@1wt.eu
 To: tattiprav...@gmail.com
 CC: haproxy@formilux.org
 Subject: Re: Query regarding extracting ssl hello sni.

 On Thu, Apr 10, 2014 at 06:30:26PM +0530, Pravin Tatti wrote:
 I think you still didn't understood the problem. There are two versions in
 SSL one is record layer hello version and the client hello version. Any
 application that support TLS versions 1.0, 1.1, 1.3 or SSLv3 (client hello
 version) may contain SSL 3.0 as the record layer version number and the
 once the negotiation is done the record layer version is updated.
 The problem is not with SSLv3 alone the problem is with all the TLS
 versions 1.0, 1.1, 1.3 or SSLv3 who has the record layer version as SSLv3
 for client hello packet.

 OK thanks for clarifying.

Basically we just need to relax the record layer check to SSLv3 - and leave
the clienthello check as is, right?

Does the attached diff do the job for you correctly, Pravin?



Regards,

Lukas





  

sslv3-record-layer-sni.diff
Description: Binary data


RE: Query regarding extracting ssl hello sni.

2014-04-10 Thread Lukas Tribus
Hi,


 Basically we just need to relax the record layer check to SSLv3 - and
 leave the clienthello check as is, right?

 Does the attached diff do the job for you correctly, Pravin?

I have reproduced the issue with gnutls and can confirm that the patch
fixes the problem.

The function now requires only SSLv3 or later in the record layer, but
still requires at least TLSv1.0 in the client hello.

I don't think any SNI capable client announces SSLv2 in the record layer
or worse.


I will submit the patch formally.



Regards,

Lukas

  


Re: Query regarding extracting ssl hello sni.

2014-04-10 Thread Pravin Tatti
I would suggest that it will not harm even if you relax the check for
client hello too as the old client can using SSL 3.0 is still supported and
its according to RFC and also note that the max supported TLS version is
3.3. I would suggest the below mentioned changes.

288c288
 /* Check for TLSv1 or later (SSL version = 3.1) */
---
 /* Check for SSLv3 or later (SSL version = 3.0) */
291c291
 if (data[1]  0x03 || data[2]  0x01)
---
 if (data[1]  0x03 || data[2]  0x03)
322c322
 if (data[0]  0x03 || data[1]  0x01) /* TLSv1 minimum */
---
 if (data[0]  0x03 || data[1]  0x03) /* SSLv3 minimum TLSv1.2
maximum */


On Fri, Apr 11, 2014 at 12:43 AM, Lukas Tribus luky...@hotmail.com wrote:

 Hi,


  Basically we just need to relax the record layer check to SSLv3 - and
  leave the clienthello check as is, right?
 
  Does the attached diff do the job for you correctly, Pravin?

 I have reproduced the issue with gnutls and can confirm that the patch
 fixes the problem.

 The function now requires only SSLv3 or later in the record layer, but
 still requires at least TLSv1.0 in the client hello.

 I don't think any SNI capable client announces SSLv2 in the record layer
 or worse.


 I will submit the patch formally.



 Regards,

 Lukas




Query regarding extracting ssl hello sni.

2014-04-09 Thread Pravin Tatti
Hi,

The function smp_fetch_ssl_hello_sni() only supports record layer version
and client hello version greater than or equal to 3.1. But as in the
RFC5246 in appendix E says that TLS versions 1.0, 1.1, and 1.2, and SSL
3.0 are very similar and also if we check the last 2 paras as mentioned
below

 Earlier versions of the TLS specification were not fully clear on what
the record layer version number (TLSPlaintext.version) should contain when
sending ClientHello (i.e., before it is known which version of the protocol
will be employed). Thus, TLS servers compliant with this specification MUST
accept any value {03,XX} as the record layer version number for
ClientHello.

TLS clients that wish to negotiate with older servers MAY send any value
{03,XX} as the record layer version number. Typical values would be
{03,00}, the lowest version number supported by the client, and the value
of ClientHello.client_version. No single value will guarantee
interoperability with all old servers, but this is a complex topic beyond
the scope of this document. 

This indicates that the tls record version might be SSL 3.0 and the client
hello might be TLS version 1.0, 1.1 or 1.2.

Do we need to consider this case while parsing in smp_fetch_ssl_hello_sni()
or is there any other specific reason for it.

I noticed such kind of issue when application is using gnutls instead of
openssl.
ie., the record layer version is SSL 3.0 and client hello is 3.3.


Hello Dear

2013-12-18 Thread Aamina Madani
Dear Friend,

I am Miss. Aamina Madani the only surviving daughter of late Mr and Mrs.Hassan 
Madani. My Family members was killed on 2011, during the crisis that leads to 
the death of Muammar al-Gaddafi on October 20 2011.

I am From Libya. My father left US$8.8 Million dollar Eight Million Eight 
Hundred Thousand US Dollar in the security company in London, I lost my father, 
Mother and my two brothers, I need somebody I can trust a some one who will not 
betray me that will receive this fund and take care of me in his or her 
country. Presently I'm in a refugee camp in, Ivory Coast in West Africa, please 
if you can be of any help do get back to me for more details.

Thanks
Accept my regards,

Aamina Madani.






hello

2013-10-31 Thread Alina Tekere

hello,
goodday how are you doing today, hope you are doing good,
my name is Alina, please i have a very important issue to discuss with you, 
please it is for our own good. i know you might not know me by mail, but please 
reply me so that i will explain myself and tell you why i mailed you
and also send you my picture
i will be waiting for your reply soon

yours faithfully,

Alina Tekere




Invitation: Hello, @ Wed Oct 16, 2013 8pm - 9pm (barrister_oxf...@sify.com)

2013-10-16 Thread barrister_oxf...@sify.com
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20131016T143000Z
DTEND:20131016T153000Z
DTSTAMP:20131016T142633Z
ORGANIZER;CN=barrister_oxf...@sify.com:mailto:barrister_oxf...@sify.com
UID:f660qo00li574j86pm433nb...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=haproxy@formilux.org;X-NUM-GUESTS=0:mailto:haproxy@formilux.org
CREATED:20131016T142628Z
DESCRIPTION:Hello\,\n \nWe send this email to confirm that you have a trans
 fer line of 5000$ by western union\, A total sum of US$5000\, 000 has been 
 approved to pay to you through western union. Your name and particulars wer
 e discovered through the list of the outstanding debts due for payment.\n \
 nAfter a meeting with the Federal Ministry of Finance\, we came to a conclu
 sion to make use of western union by sending this money install mentally at
  the rate of 5000$ per day till your reach payment of $600\,000 is fully tr
 ansferred.\n \nFor your information\, A transfer of 5000$ have just been af
 fected in your name. Below are the sending information's\n*
 ***
 \n \nSenders name. Lukas Imo\nMtcn numbers.
  922-583-1302\nAmount. USA   $5000. 00\nQuestion How are you\nAnwser.  
 I am fine\n \n \nYou must contact Rev Imo Lukas via email: (imo_lukas04
 5...@outlook.fr) for more details to you\,Note you must provide the following 
 information’s to Rev Imo Lukas:\n \nYour Full Name:\nTelephone and Fax Numb
 er:\nResidential Address:\nBest regards\,\nNatasha Dagogo\nFor  management\
 nPICK UP YOUR PAYMENT OF $5000\nView your event at http://www.google.com/ca
 lendar/event?action=VIEWeid=ZjY2MHFvMDBsaTU3NGo4NnBtNDMzbmIzODQgaGFwcm94eU
 Bmb3JtaWx1eC5vcmctok=MjUjYmFycmlzdGVyX294Zm9yZEBzaWZ5LmNvbTczOWRmMWM5M2E3Z
 DRhYmUyZTE1N2QzOTJkM2FjZWVhYTZjZjAxYzEctz=Asia/Calcuttahl=en.
LAST-MODIFIED:20131016T142628Z
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Hello\,
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics


Haproxy ssl-hello-chk and check

2012-10-22 Thread Kevin COUSIN
Hi,

I just setup an HAProxy for a RDS platform. I must set ssl-hello-chk option to 
get it works, but i can't set server check options with ssl-hello-chk, haproxy 
said haproxy[5059]: backend FARM has no server available. Is it normal ?

Here is my conf:

global
log 127.0.0.1 local4
maxconn 65535
ulimit-n 131085
   defaults
log global
clitimeout 1h
srvtimeout 1h

   frontend Frontal-RDS
bind :3389,:135,:139
default_backend FARM
# Options
tcp-request inspect-delay 5s
tcp-request content accept if RDP_COOKIE
timeout client 1h
monitor-net 10.20.20.248/29

   backend FARM
mode tcp
persist rdp-cookie
balance rdp-cookie
#balance leastconn

timeout connect 4s
log 127.0.0.1 local4
option redispatch
option tcpka
option tcplog
# Pour les connexions RDP sécurisées ?
option ssl-hello-chk
timeout server 1h

# sticky persistence
#stick-table type string len 32 size 10k expire 1d
#stick on rdp-cookie


server SRV1 SRV1.local weight 1
server SRV2 SRV2.local weight 1

  listen stats :1936
mode http
stats enable
stats hide-version
stats realm Haproxy\ Statistics
stats uri /
stats auth user:secret



   Kevin C.




Re: Haproxy ssl-hello-chk and check

2012-10-22 Thread Baptiste
Hi,

You forgot the directive 'check' on each server line.

HAProxy only process health checks on the server you told it to do.

cheers


On Mon, Oct 22, 2012 at 3:34 PM, Kevin COUSIN ki...@kiven.fr wrote:
 Hi,

 I just setup an HAProxy for a RDS platform. I must set ssl-hello-chk option 
 to get it works, but i can't set server check options with ssl-hello-chk, 
 haproxy said haproxy[5059]: backend FARM has no server available. Is it 
 normal ?

 Here is my conf:

 global
 log 127.0.0.1 local4
 maxconn 65535
 ulimit-n 131085
defaults
 log global
 clitimeout 1h
 srvtimeout 1h

frontend Frontal-RDS
 bind :3389,:135,:139
 default_backend FARM
 # Options
 tcp-request inspect-delay 5s
 tcp-request content accept if RDP_COOKIE
 timeout client 1h
 monitor-net 10.20.20.248/29

backend FARM
 mode tcp
 persist rdp-cookie
 balance rdp-cookie
 #balance leastconn

 timeout connect 4s
 log 127.0.0.1 local4
 option redispatch
 option tcpka
 option tcplog
 # Pour les connexions RDP sécurisées ?
 option ssl-hello-chk
 timeout server 1h

 # sticky persistence
 #stick-table type string len 32 size 10k expire 1d
 #stick on rdp-cookie


 server SRV1 SRV1.local weight 1
 server SRV2 SRV2.local weight 1

   listen stats :1936
 mode http
 stats enable
 stats hide-version
 stats realm Haproxy\ Statistics
 stats uri /
 stats auth user:secret

 

Kevin C.





Re: Haproxy ssl-hello-chk and check

2012-10-22 Thread Hervé COMMOWICK
Hello Kevin,

You didn't set the check port, and as you specify server address without
port number on server line, it can't work.
Add check port 3389 on each server line but i think you can't use
persist rdp-cookie if you want to use TLS as in
http://support.microsoft.com/kb/895433 because Haproxy will not be able
to see RDP Cookies...

Hervé.

On 10/22/2012 03:34 PM, Kevin COUSIN wrote:
 Hi,
 
 I just setup an HAProxy for a RDS platform. I must set ssl-hello-chk option 
 to get it works, but i can't set server check options with ssl-hello-chk, 
 haproxy said haproxy[5059]: backend FARM has no server available. Is it 
 normal ?
 
 Here is my conf:
 
 global
 log 127.0.0.1 local4
 maxconn 65535
 ulimit-n 131085
defaults
 log global
 clitimeout 1h
 srvtimeout 1h
 
frontend Frontal-RDS
 bind :3389,:135,:139
 default_backend FARM
 # Options
 tcp-request inspect-delay 5s
 tcp-request content accept if RDP_COOKIE
 timeout client 1h
 monitor-net 10.20.20.248/29
 
backend FARM
 mode tcp
 persist rdp-cookie
 balance rdp-cookie
 #balance leastconn
 
 timeout connect 4s
 log 127.0.0.1 local4
 option redispatch
 option tcpka
 option tcplog
 # Pour les connexions RDP sécurisées ?
 option ssl-hello-chk
 timeout server 1h
 
 # sticky persistence
 #stick-table type string len 32 size 10k expire 1d
 #stick on rdp-cookie
 
 
 server SRV1 SRV1.local weight 1
 server SRV2 SRV2.local weight 1
 
   listen stats :1936
 mode http
 stats enable
 stats hide-version
 stats realm Haproxy\ Statistics
 stats uri /
 stats auth user:secret
 
 
 
Kevin C.
 
 

-- 
Hervé COMMOWICK
Ingénieur systèmes et réseaux.

http://www.rezulteo.com
by Lizeo Online Media Group http://www.lizeo-online-media-group.com/
42 quai Rambaud - 69002 Lyon (France) ⎮ ☎ +33 (0)4 63 05 95 30



Re: Hello

2012-09-17 Thread Applications
Dear applicant 

Thank you for your application to the above position. We will review all 
applications received shortly after the closing date and will be in contact 
with you thereafter.

Please ensure that you have provided as much information as possible in your CV 
- this will help to ensure that we are able to make an informed selection 
decision based on your specific skills and experience. 

Kind regards,

Recruitment Office

 haproxy@formilux.org 09/17/12 08:05 

OXP7¢cyw*¼^¿,¿ø.ùó‡Wœï~ÉWáq4èH¢ëaxF¹Tk1rñ
µÑq(ÔšÇ*ã‡ààiKw*ʯØÖ‚!5*6¯:*u\X…G|¬*ø5cª Ü™†¬Âí…6Á*À¹;ç^ß
Öå,ÙQfz}-œÅ3³mNëZÇÙ:/Ì{¡´¯¨mºo2^2“ë䆺ºâ3*ì,i*›ÊÁáª-3›ÀßÔ®ã.a«
‰µ„/Xö~¼§*Bg‡d\ZuRÀ3;W]{ì8*zî*®$^qÆ1sŒé(*uòoMF‹)EÍï¹Æ7†éäê‹~æìjn 
;#ç¥Éd®4µÇ²}*£\~HhšÖ*7*XALú0Œ*Üç¶(l~ÀQ'#‘´«nbp*ï²H±ò½8»iñüúàùig©näs¡1‡BaÂJËì¹yùi[3Gßó*-2*éç%öVs
R1Ø~ê—×VjIo6ágsq0œv¬ãW‡ïq5†cé¾'k±ƒ*jT\MH*âÏôÓD3¶á»vyÕ³øãc§Üko»S“‘{z©\É|ª]K#¯“ùÉgG£*»4Ád„×ÓòØÖe‡8N}[”¯ùã²xx:]å#M§*²Áùâì]*ïÒ©Xìš‘rhä7‹*xGÜ}yG{¯pÂ*v**
 7øN’¯Ñ‰æ‘Ô*ÛÍîYK´VäœÍ¹¶á*å‚´:Kp
J\Tg¹îRB-ójNå$o%p˜v‚n-óIü°a*sÔ”ûóì‡G:éÜ9£H.óTOÉX‰ÈsŠ¬n‰Ê-*Í-„†ák5Ì-*’½Ì/**òñÂ*wÏñ¥´Â5ôhÉH|®Z׳©'÷*kJçQgç½*æo2˜Æ3âL*J|¹¾?
NÒé)[°%
÷'Ó#¾ïÛx¬´t0Ä–”}÷ûb1*ùóÀ*ìsø--*_çº|牺U\A…T*¬sÈ’²úɉ3*Á±s»à
ç†|*±gdgìÅamB[ŒÏjhbîOÒÚ*¬“*§*vk“yCBérÁAÑà 
‡*5¶xm12§»_*HU„B2**ã3svÈ2²…|ŠÌv¼E`«›‘2il° #Ù!úí±:K
§*B**jÇFsï¨ú´OÜ|QO_£æzR~*/بQé«ÃfÇ®
¶x9ÎÒg{Õ0zuQ°ì*¯t.p¼ŒÍõÓõpït:œ$5ï9’
²Ï8¶ƒVÔù‘,SÅä*–ûgƒ–#llÉ)**eà9 a”**‡àã**o‹q‹OFg*q—òß½ñ*ÌC‹h„jö§
ŠN¥ZUÍ›-p*©v)‚*®*ØL‹ù72›:¹Ö²s!¬aÌ‹y:6;`䧌çI^èPN?dOy*uÍ¢!)é*
e¡á}*ÖN:®eRHIÑ
'û3s¶›:}H*éôí*g‘—V7S{ëÓï5£¥ÁWÀ*ç$**#
bÕ9tj™vèKç»**Õ×Fë*œ*Ùï#šÑ*÷L‡ç;/m2oËzM#Õ*£Š7ë#¬P±[a¼‹#·פ4¹›ÖP]”§§qi*;[ù«tóÕÔÖë2îY÷iqõ/Ñ™*
pÈ4[K……û*ÍifZ*Y÷%ß—UÌœMÃÊ„©çB¿ÜHv*MÎè$Ìë˜[æ*Ñå´i3tß×ÑK8ÅVJõ|sd°n*g*”ÄN»M¯Ï§3!Ê*uÛï´*M°¼óX¤*CõY‡®h»‚|*¤õtÊܘY´ø4.BïbæJôÀÈ*÷ŠC3œ-|Tyê-?qŒ*‡
v—œ*ÖuÅÀx…ß^‚-r
°å*-*NöÑrZl**o±œ,¶;*ÀµH**¶”|uËìy…:ÃLdöLŠ÷*8Ö|Æçglº[MÍtÙ7oM¡dÚ¼â%™W
‡
:I#l9Ô§!S©c×ÆFÃ/4sÆ\Ö/ƒ*„A4#–*Ë¢ßøîö
-ûŠûBÈJ*î§*‡“Yø¶Bd¨;’Ùºg0*©¶**ÚH*o`šSÍÚ*¥š*Ô‹]ÕHS»ø‘*oP*o!õ*qÆ͢ *-Eà_¯Ë¤
‹ß
ù²*k„m.†F|÷é¼I˜èsK$g*×9[MèÄÚ{ã*ƒ*TpøpGšéO‘}wÁ
©*¨îæÆb-u„’*N˜FÓl×oöá‹â°[¢¿;ïá:¨q†áÛy°/*-õ%ü0o#$îR«î¶ZëÄ›t1{¤ÚZÛAB*éœ*w0Ã÷äu:*ÓBã]*ÚäK%eiT.Zâ˜ù*Q¤õ3c6,kq‡±*«’*ä%F4*áò¢?èà!ÖkRªm×ê*óºÕ8¢„j*;’T__;„~õ›,Xü82qb**¯**…ÒÄê°§í
 ûò‰vÕô}‰¥C3}Qn*;ç*4O,æW*“n
™}BÜõj`)7›˜.ÈËμ
àºë¿Ü1*ÏÛëä3’Ã**”! UL3™.âz;æeÍD3
idNÔBQ$¡7Ä*œØÄ)©¬]n**%š*/yyÑg¤÷7öo*AS»ö*Á¹î“çDsæ*Aa‡ÏBÔŠn{±æI*¯¾É¿äS±*ïHwBá*
:0Š»03i[yšÕR
é±wÎÒkÍ‘á÷Å
*é©ßLbå˜c”!ò”Q¤ú|**׃.zd*Ò$ÚQ
uò½‚]eâãç[ ^I,9ï§Qâ徘µMe86*1
ñ
:»¢C*©
œ‚O¤PÓ*8‚èXCî-*R**ÙNŠ|÷r
áF;gYÁ—(1‚*”a™-†L’Bö-ño%*zjFö4Qz*³ëÛª²AaÈ`s_*aôxC5G*hô*JÅhÂÅ$pùZ*¥Î\îÛØ3I¾Éàg÷™üR\\µ¢~s*‘Û„X4*yh
X9†J;º³½àî\ç¡*f¿Z7R**P³ƒp³©gNöùf¯âÌ—Pœ.±GÒ


The views and opinions expressed in this email may not necessarily be that of 
the Department of Trade and Industry. Please click on the attached link for the 
official dti disclaimer. 
http://www.thedti.gov.za/disclaimer/disclaimer-plain.htm


Hello

2011-11-03 Thread Prince Ojie
Hello 
i AM PRINCE OJIE 20YRS OLD  I HAVE VERY IMPORTANT ISSUE TO DISCUSS WITH YOU 
PLEASE KINDLY CONTACT ME URGENTLY  ON E-MAIL : princeo...@live.com 
+233269420345 
Regards 
Prince Ojie



HELLO

2011-04-07 Thread Anita Abdul


I am writing this letter out of a genuine desperation to find a reliable 
partner in an unfolding transaction. I seek your help and
genuine co-operation to our mutual benefit and I believe that you will
not letdown the trust and confidence I am about to repose on you. I am
Anita, Purchasing Manager to Gss solid minerals company. I used to represent my 
company to several Asian countries to purchase a product called Xsp solution, 
this is a chemical liquid use for cleaning Gold,
Silvers, Stones and soon. Now, our company want to send another staff from our 
company duo to my inability to travel this time, that's why am contacting you.


I will introduce you to my company's General Manager as the main supplier of 
the chemical. Per packet of the vaccine cost $6,500 in
UNITED STATE, but in Asia Malaysia where I have been purchasing, it only cost 
$2,500 per packet and you will supply to my company at the
rate of $5,100.Per packet.


Note, do not disclose the actual cost of the chemical i.e. $2,500 to my
company GM as this will affect our profit. My company's directors don't know 
the seller of this product and the seller doesn't know my company directors, I 
'll introduce you as the main supplier. My company normally purchase 20, 
30-150cartons in each trip I make depending on the product we have left in the 
company. The distributor of this
product is a Malaysian, you will purchase the product from the Malaysian dealer 
and supply to my company, my company will now pay you
cash on delivery.


Let the above mentioned be in mutual beneficiary for us and an opportunity to 
embark in future engagements. If you wish to take up this offer, kindly mail me 
and I will reply you with all the contact details and that of my GM whom you 
will contact and send you quotation. I will also give
you the price to quote.If you have any question, feel free to ask or
contact me through my personal e-mail
(anitaabdulra...@hotmail.co.uk)


Best regards
Anita Abdul Razak
GSS Solid Minerals
E-mail: anitaabdulra...@hotmail.co.uk


HELLO

2011-04-05 Thread Anita Abdul


I am writing this letter out of a genuine desperation to find a reliable 
partner in an unfolding transaction. I seek your help and
genuine co-operation to our mutual benefit and I believe that you will
not letdown the trust and confidence I am about to repose on you. I am
Anita, Purchasing Manager to Gss solid minerals company. I used to represent my 
company to several Asian countries to purchase a product called Xsp solution, 
this is a chemical liquid use for cleaning Gold,
Silvers, Stones and soon. Now, our company want to send another staff from our 
company duo to my inability to travel this time, that's why am contacting you.


I will introduce you to my company's General Manager as the main supplier of 
the chemical. Per packet of the vaccine cost $6,500 in
UNITED STATE, but in Asia Malaysia where I have been purchasing, it only cost 
$2,500 per packet and you will supply to my company at the
rate of $5,100.Per packet.


Note, do not disclose the actual cost of the chemical i.e. $2,500 to my
company GM as this will affect our profit. My company's directors don't know 
the seller of this product and the seller doesn't know my company directors, I 
'll introduce you as the main supplier. My company normally purchase 20, 
30-150cartons in each trip I make depending on the product we have left in the 
company. The distributor of this
product is a Malaysian, you will purchase the product from the Malaysian dealer 
and supply to my company, my company will now pay you
cash on delivery.


Let the above mentioned be in mutual beneficiary for us and an opportunity to 
embark in future engagements. If you wish to take up this offer, kindly mail me 
and I will reply you with all the contact details and that of my GM whom you 
will contact and send you quotation. I will also give
you the price to quote.If you have any question, feel free to ask or
contact me through my personal e-mail
(anitaabdulra...@hotmail.co.uk)


Best regards
Anita Abdul Razak
GSS Solid Minerals
E-mail: anitaabdulra...@hotmail.co.uk