Hi!
I've created a patch that enables PHP to do "limited wildcard
matching" if CN_match option in stream context is specified as
'*.example.org'.
Also I have filled a bug report for this, here:
http://bugs.php.net/bug.php?id=51100
Patch is here:
http://source.a2o.si/php/php-ext-openssl-CN_match-wildcard.diff
It was made against 5.2.12 but I checked it with SVN:
- for 5.2 branch the offset is only +6 lines
- for trunk it is cca +800 lines
Can you include it in 5.2.13 release and 5.3? I know the former is
already in RC stage but this does can't break anything I believe.
Best regards,
b.
hi,
Is it not suppose to work already? As your patch basically does what
is done earlier in the code if match fails. If there is a bug in this
area, we should fix instead of adding the same thing later :)
I will check this issue next week.
Btw, there is no chance to get this in 5.2.13 or 5.3.2 at this stage,
it is too late in the process.
Thanks for your work!
Cheers,
Hi!
I've created a patch that enables PHP to do "limited wildcard
matching" if CN_match option in stream context is specified as
'*.example.org'.
Also I have filled a bug report for this, here:
http://bugs.php.net/bug.php?id=51100Patch is here:
http://source.a2o.si/php/php-ext-openssl-CN_match-wildcard.diffIt was made against 5.2.12 but I checked it with SVN:
- for 5.2 branch the offset is only +6 lines
- for trunk it is cca +800 lines
Can you include it in 5.2.13 release and 5.3? I know the former is
already in RC stage but this does can't break anything I believe.Best regards,
b.--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
The patch includes code which is very similar but it's functionality
goes just the other way around.
The original code takes remote CN and if that contains asterisk, it
tries to 'limited-wildcard-match' of CN_match against remote CN
(remote CN is the pattern in this case, if you will).
On the other hand, added code checks if CN_match contains asterisk and
if so, it does 'limited-wildcard-match' of REMOTE CN against CN_match
pattern.
The original version 'could' be enough if you are only considering PHP
as a SSL client.
Now, what I am trying to achieve is a whole standalone application
server written in PHP. That is, whole forking/process management etc
stuff. And I would like to set it up like this:
- it has a SSL listening socket
- set CN_match for listening socket to '*.example.org'
- create listening socket with stream_socket_server
All above in order to accept connections only from clients which
present themselves with appropriate certificate (based on cacert check
which works OK) and appropriate CN.
To illustrate the desired functionality:
- CNs host1.example.org and host2.example.org are OK,
- but not CN host3.otherdomain.org, even if it presents a certificate
from the same CA as the two above.
Was I clear enough now? :)
b.
PS: I've just discovered another issue. In the context of creating
listening socket with stream_socket_create, again.
If a preceeding SSL client has introduced itself with client
certificate, and the current client does not, the
[ssl][peer_certificate] of the new socket's context options still
contains a reference to a resource of preceeding client's certificate.
Later, subsequent client connections without certificate do not
exhibit the same behaviour.
If the pattern reoccurs (... ---> client-with-cert ---> followed by
client-without-cert), the story repeats.
There is also a memory leak in this - when I looped the client to
establish hundreds of sequential SSL connections, the residental
memory footprint of php server process was ever increasing. When I
switched my App server to HTTP protocol and repeated the test the
memory leak was not present anymore. And I did openssl_x509_free()
call on peer_certificate resource upon client disconnect.
hi,
Is it not suppose to work already? As your patch basically does what
is done earlier in the code if match fails. If there is a bug in this
area, we should fix instead of adding the same thing later :)I will check this issue next week.
Btw, there is no chance to get this in 5.2.13 or 5.3.2 at this stage,
it is too late in the process.Thanks for your work!
Cheers,
Hi!
I've created a patch that enables PHP to do "limited wildcard
matching" if CN_match option in stream context is specified as
'*.example.org'.
Also I have filled a bug report for this, here:
http://bugs.php.net/bug.php?id=51100Patch is here:
http://source.a2o.si/php/php-ext-openssl-CN_match-wildcard.diffIt was made against 5.2.12 but I checked it with SVN:
- for 5.2 branch the offset is only +6 lines
- for trunk it is cca +800 lines
Can you include it in 5.2.13 release and 5.3? I know the former is
already in RC stage but this does can't break anything I believe.Best regards,
b.--
--
Pierre@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
a) If you would like to see an example of memory leak, here is how I
reproduce it.
-
Clone this git repository:
http://github.com/bostjan/PHP-application-server -
Copy/move/Symlink contents to /opt/daemons/AppSrv
-
cd to /opt/daemons/AppSrv/demos/demo_https
-
start the daemon: ./demo -d5
- binds and listens on port 30000
- does not fork into background
-
execute ./client_openssl_nocert
-
with another shell go to: /opt/daemons/AppSrv/demos/demo_https
-
execute this: while (true); do ./client_curl; done
-
start another shell and watch increasing residental memory of PHP
server process
b) If you would like to see an example of stale openssl_x509 resource
bug, here is how I reproduce it.
Follow the steps 1-5 above
- execute ./client_openssl
- make some input, double return
- watch at server console how correct CN appears two times
- execute ./client_openssl_nocert
- watch at server console how STALE CN from previous connection appears
- execute ./client_openssl_nocert
- and the bug is gone to hiding
- If you repeat steps 6-8 bug reappears/redissapears.
I hope this helps,
b.
The patch includes code which is very similar but it's functionality
goes just the other way around.The original code takes remote CN and if that contains asterisk, it
tries to 'limited-wildcard-match' of CN_match against remote CN
(remote CN is the pattern in this case, if you will).On the other hand, added code checks if CN_match contains asterisk and
if so, it does 'limited-wildcard-match' of REMOTE CN against CN_match
pattern.The original version 'could' be enough if you are only considering PHP
as a SSL client.Now, what I am trying to achieve is a whole standalone application
server written in PHP. That is, whole forking/process management etc
stuff. And I would like to set it up like this:
- it has a SSL listening socket
- set CN_match for listening socket to '*.example.org'
- create listening socket with stream_socket_server
All above in order to accept connections only from clients which
present themselves with appropriate certificate (based on cacert check
which works OK) and appropriate CN.To illustrate the desired functionality:
- CNs host1.example.org and host2.example.org are OK,
- but not CN host3.otherdomain.org, even if it presents a certificate
from the same CA as the two above.Was I clear enough now? :)
b.PS: I've just discovered another issue. In the context of creating
listening socket with stream_socket_create, again.If a preceeding SSL client has introduced itself with client
certificate, and the current client does not, the
[ssl][peer_certificate] of the new socket's context options still
contains a reference to a resource of preceeding client's certificate.
Later, subsequent client connections without certificate do not
exhibit the same behaviour.
If the pattern reoccurs (... ---> client-with-cert ---> followed by
client-without-cert), the story repeats.There is also a memory leak in this - when I looped the client to
establish hundreds of sequential SSL connections, the residental
memory footprint of php server process was ever increasing. When I
switched my App server to HTTP protocol and repeated the test the
memory leak was not present anymore. And I didopenssl_x509_free()
call on peer_certificate resource upon client disconnect.hi,
Is it not suppose to work already? As your patch basically does what
is done earlier in the code if match fails. If there is a bug in this
area, we should fix instead of adding the same thing later :)I will check this issue next week.
Btw, there is no chance to get this in 5.2.13 or 5.3.2 at this stage,
it is too late in the process.Thanks for your work!
Cheers,
Hi!
I've created a patch that enables PHP to do "limited wildcard
matching" if CN_match option in stream context is specified as
'*.example.org'.
Also I have filled a bug report for this, here:
http://bugs.php.net/bug.php?id=51100Patch is here:
http://source.a2o.si/php/php-ext-openssl-CN_match-wildcard.diffIt was made against 5.2.12 but I checked it with SVN:
- for 5.2 branch the offset is only +6 lines
- for trunk it is cca +800 lines
Can you include it in 5.2.13 release and 5.3? I know the former is
already in RC stage but this does can't break anything I believe.Best regards,
b.--
--
Pierre@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi,
can you run it through valgrind and paste the output in a new bug report please?
Cheers,
a) If you would like to see an example of memory leak, here is how I
reproduce it.
Clone this git repository:
http://github.com/bostjan/PHP-application-serverCopy/move/Symlink contents to /opt/daemons/AppSrv
cd to /opt/daemons/AppSrv/demos/demo_https
start the daemon: ./demo -d5
- binds and listens on port 30000
- does not fork into background
execute ./client_openssl_nocert
with another shell go to: /opt/daemons/AppSrv/demos/demo_https
execute this: while (true); do ./client_curl; done
start another shell and watch increasing residental memory of PHP
server processb) If you would like to see an example of stale openssl_x509 resource
bug, here is how I reproduce it.
Follow the steps 1-5 above
- execute ./client_openssl
- make some input, double return
- watch at server console how correct CN appears two times
- execute ./client_openssl_nocert
- watch at server console how STALE CN from previous connection appears
- execute ./client_openssl_nocert
- and the bug is gone to hiding
- If you repeat steps 6-8 bug reappears/redissapears.
I hope this helps,
b.The patch includes code which is very similar but it's functionality
goes just the other way around.The original code takes remote CN and if that contains asterisk, it
tries to 'limited-wildcard-match' of CN_match against remote CN
(remote CN is the pattern in this case, if you will).On the other hand, added code checks if CN_match contains asterisk and
if so, it does 'limited-wildcard-match' of REMOTE CN against CN_match
pattern.The original version 'could' be enough if you are only considering PHP
as a SSL client.Now, what I am trying to achieve is a whole standalone application
server written in PHP. That is, whole forking/process management etc
stuff. And I would like to set it up like this:
- it has a SSL listening socket
- set CN_match for listening socket to '*.example.org'
- create listening socket with stream_socket_server
All above in order to accept connections only from clients which
present themselves with appropriate certificate (based on cacert check
which works OK) and appropriate CN.To illustrate the desired functionality:
- CNs host1.example.org and host2.example.org are OK,
- but not CN host3.otherdomain.org, even if it presents a certificate
from the same CA as the two above.Was I clear enough now? :)
b.PS: I've just discovered another issue. In the context of creating
listening socket with stream_socket_create, again.If a preceeding SSL client has introduced itself with client
certificate, and the current client does not, the
[ssl][peer_certificate] of the new socket's context options still
contains a reference to a resource of preceeding client's certificate.
Later, subsequent client connections without certificate do not
exhibit the same behaviour.
If the pattern reoccurs (... ---> client-with-cert ---> followed by
client-without-cert), the story repeats.There is also a memory leak in this - when I looped the client to
establish hundreds of sequential SSL connections, the residental
memory footprint of php server process was ever increasing. When I
switched my App server to HTTP protocol and repeated the test the
memory leak was not present anymore. And I didopenssl_x509_free()
call on peer_certificate resource upon client disconnect.hi,
Is it not suppose to work already? As your patch basically does what
is done earlier in the code if match fails. If there is a bug in this
area, we should fix instead of adding the same thing later :)I will check this issue next week.
Btw, there is no chance to get this in 5.2.13 or 5.3.2 at this stage,
it is too late in the process.Thanks for your work!
Cheers,
Hi!
I've created a patch that enables PHP to do "limited wildcard
matching" if CN_match option in stream context is specified as
'*.example.org'.
Also I have filled a bug report for this, here:
http://bugs.php.net/bug.php?id=51100Patch is here:
http://source.a2o.si/php/php-ext-openssl-CN_match-wildcard.diffIt was made against 5.2.12 but I checked it with SVN:
- for 5.2 branch the offset is only +6 lines
- for trunk it is cca +800 lines
Can you include it in 5.2.13 release and 5.3? I know the former is
already in RC stage but this does can't break anything I believe.Best regards,
b.--
--
Pierre@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Below is the valgrind output. Seem like it is OpenSSL's fault? Thus I am not
filling another bug report. Or can you do anything about it?
b.
==12933==
==12933== IN SUMMARY: 563339 errors from 307 contexts (suppressed: 69 from
==12933==
==12933== malloc/free: in use at exit: 1,628 bytes in 44 blocks.
==12933== malloc/free: 25,390 allocs, 25,346 frees, 3,335,313 bytes
allocated.
==12933==
==12933== searching for pointers to 44 not-freed blocks.
==12933== checked 1,023,180 bytes.
==12933==
==12933==
==12933== 348 bytes in 30 blocks are definitely lost in loss record 2 of 3
==12933== at 0x40237B9: malloc (in
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==12933== by 0x4261D9A: default_malloc_ex (in
/usr/local/openssl-0.9.8l-1/lib/libcrypto.so.0.9.8)
==12933==
==12933== LEAK SUMMARY:
==12933== definitely lost: 348 bytes in 30 blocks.
==12933== possibly lost: 0 bytes in 0 blocks.
==12933== still reachable: 1,280 bytes in 14 blocks.
==12933== suppressed: 0 bytes in 0 blocks.
==12933== Reachable blocks (those to which a pointer was found) are not
shown.
==12933== To see them, rerun with: --leak-check=full --show-reachable=yes
--12933-- memcheck: sanity checks: 165 cheap, 8 expensive
--12933-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use
--12933-- memcheck: auxmaps_L1: 0 searches, 0 cmps, ratio 0:10
--12933-- memcheck: auxmaps_L2: 0 searches, 0 nodes
--12933-- memcheck: SMs: n_issued = 102 (1632k, 1M)
--12933-- memcheck: SMs: n_deissued = 9 (144k, 0M)
--12933-- memcheck: SMs: max_noaccess = 65535 (1048560k, 1023M)
--12933-- memcheck: SMs: max_undefined = 3 (48k, 0M)
--12933-- memcheck: SMs: max_defined = 737 (11792k, 11M)
--12933-- memcheck: SMs: max_non_DSM = 98 (1568k, 1M)
--12933-- memcheck: max sec V bit nodes: 1189 (60k, 0M)
--12933-- memcheck: set_sec_vbits8 calls: 167151 (new: 1189, updates:
--12933-- memcheck: max shadow mem size: 1932k, 1M
--12933-- translate: fast SP updates identified: 83,889 ( 93.1%)
--12933-- translate: generic_known SP updates identified: 4,337 ( 4.8%)
--12933-- translate: generic_unknown SP updates identified: 1,816 ( 2.0%)
--12933-- tt/tc: 87,945 tt lookups requiring 121,849 probes
--12933-- tt/tc: 87,945 fast-cache updates, 4 flushes
--12933-- transtab: new 28,388 (755,681 -> 12,187,193; ratio 161:10)
[0 scs]
--12933-- transtab: dumped 0 (0 -> ??)
--12933-- transtab: discarded 186 (3,146 -> ??)
--12933-- scheduler: 16,567,751 jumps (bb entries).
--12933-- scheduler: 165/111,191 major/minor sched events.
--12933-- sanity: 166 cheap, 8 expensive checks.
--12933-- exectx: 12,289 lists, 11,746 contexts (avg 0 per list)
--12933-- exectx: 614,084 searches, 611,160 full compares (995 per 1000)
--12933-- exectx: 1,029,878 cmp2, 839,523 cmp4, 0 cmpAll
--12933-- errormgr: 318 supplist searches, 318 comparisons during search
--12933-- errormgr: 563,408 errlist searches, 2,219,261 comparisons during
search
hi,
can you run it through valgrind and paste the output in a new bug report
please?Cheers,
a) If you would like to see an example of memory leak, here is how I
reproduce it.
Clone this git repository:
http://github.com/bostjan/PHP-application-serverCopy/move/Symlink contents to /opt/daemons/AppSrv
cd to /opt/daemons/AppSrv/demos/demo_https
start the daemon: ./demo -d5
- binds and listens on port 30000
- does not fork into background
execute ./client_openssl_nocert
with another shell go to: /opt/daemons/AppSrv/demos/demo_https
execute this: while (true); do ./client_curl; done
start another shell and watch increasing residental memory of PHP
server processb) If you would like to see an example of stale openssl_x509 resource
bug, here is how I reproduce it.
Follow the steps 1-5 above
- execute ./client_openssl
- make some input, double return
- watch at server console how correct CN appears two times
- execute ./client_openssl_nocert
- watch at server console how STALE CN from previous connection appears
- execute ./client_openssl_nocert
- and the bug is gone to hiding
- If you repeat steps 6-8 bug reappears/redissapears.
I hope this helps,
b.The patch includes code which is very similar but it's functionality
goes just the other way around.The original code takes remote CN and if that contains asterisk, it
tries to 'limited-wildcard-match' of CN_match against remote CN
(remote CN is the pattern in this case, if you will).On the other hand, added code checks if CN_match contains asterisk and
if so, it does 'limited-wildcard-match' of REMOTE CN against CN_match
pattern.The original version 'could' be enough if you are only considering PHP
as a SSL client.Now, what I am trying to achieve is a whole standalone application
server written in PHP. That is, whole forking/process management etc
stuff. And I would like to set it up like this:
- it has a SSL listening socket
- set CN_match for listening socket to '*.example.org'
- create listening socket with stream_socket_server
All above in order to accept connections only from clients which
present themselves with appropriate certificate (based on cacert check
which works OK) and appropriate CN.To illustrate the desired functionality:
- CNs host1.example.org and host2.example.org are OK,
- but not CN host3.otherdomain.org, even if it presents a certificate
from the same CA as the two above.Was I clear enough now? :)
b.PS: I've just discovered another issue. In the context of creating
listening socket with stream_socket_create, again.If a preceeding SSL client has introduced itself with client
certificate, and the current client does not, the
[ssl][peer_certificate] of the new socket's context options still
contains a reference to a resource of preceeding client's certificate.
Later, subsequent client connections without certificate do not
exhibit the same behaviour.
If the pattern reoccurs (... ---> client-with-cert ---> followed by
client-without-cert), the story repeats.There is also a memory leak in this - when I looped the client to
establish hundreds of sequential SSL connections, the residental
memory footprint of php server process was ever increasing. When I
switched my App server to HTTP protocol and repeated the test the
memory leak was not present anymore. And I didopenssl_x509_free()
call on peer_certificate resource upon client disconnect.hi,
Is it not suppose to work already? As your patch basically does what
is done earlier in the code if match fails. If there is a bug in this
area, we should fix instead of adding the same thing later :)I will check this issue next week.
Btw, there is no chance to get this in 5.2.13 or 5.3.2 at this stage,
it is too late in the process.Thanks for your work!
Cheers,
On Sat, Feb 20, 2010 at 8:56 PM, Bostjan Skufca bostjan@a2o.si
wrote:Hi!
I've created a patch that enables PHP to do "limited wildcard
matching" if CN_match option in stream context is specified as
'*.example.org'.
Also I have filled a bug report for this, here:
http://bugs.php.net/bug.php?id=51100Patch is here:
http://source.a2o.si/php/php-ext-openssl-CN_match-wildcard.diffIt was made against 5.2.12 but I checked it with SVN:
- for 5.2 branch the offset is only +6 lines
- for trunk it is cca +800 lines
Can you include it in 5.2.13 release and 5.3? I know the former is
already in RC stage but this does can't break anything I believe.Best regards,
b.--
--
Pierre@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
Pierre@pierrejoye | http://blog.thepimp.net | http://www.libgd.org