The Apache Haus Forum

Advanced search  

News:

Welcome to Apache Haus Distribution Forum

Pages: [1] 2 3 ... 10
 1 
 on: March 27, 2020, 07:47:32 PM 
Started by RichV - Last post by RichV
I think I figured it out. I had to make <directory> point to the tomcat webapp folder and I had to put JKMount in the <VirtualHost> area, it was not taking it from my mod_jk.conf file like in the base httpd.con file. If anyone see some errors or a better solution please post away.

 2 
 on: March 27, 2020, 01:09:36 PM 
Started by RichV - Last post by RichV
Morning,
   We are running Appache httpd for Windows and trying to connect it to Tomcat via mod_jk. I have the httpd.conf setup and working. However, I cannot send this over https port 443 to secure authentication of the app. Part of what httpd is doing is making it easier to reach the application and is handling the authentication via mod_ldap (ldaps) to our AD Server. I want to ensure nothing from the client to the server is sent unencrypted. Can someone direct me in the proper way to setup  httpd_ahssl.conf? I have it working fine for /server-status but never finds the directory for the application. I know it has something to do with th RootDirectory and the mod_jk configs. Can we not just pass the conf over to httpd.conf but still use ssl? Sorry I am not a webadmin but I did sleep at a holiday inn.

 3 
 on: March 03, 2020, 01:30:04 AM 
Started by JC - Last post by JC
Thanks for your reply. Yes this was from Nessus agent.

 4 
 on: February 25, 2020, 12:30:44 PM 
Started by Sob - Last post by Jan-E
Yeah, I tried all of the pre-compiled builds I could find Jan-E and I still can't get it to run.
I am sure the GeoIP and ssh2 extensions on https://www.apachelounge.com/viewtopic.php?t=6359 work. A phpinfo.htm in the zips is the proof.

 5 
 on: February 17, 2020, 08:55:19 AM 
Started by Gene - Last post by mario
Just my 2 cents: run httpd.exe -M to see if the required module is really loaded

 6 
 on: February 17, 2020, 01:48:57 AM 
Started by Gene - Last post by Gregg
Hmmmm, this is with the current download here with the config we ship. I only uncommented the loadmodule line;

Code: [Select]
D:\curl>curl -k --http2 -v https://localhost
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_CHACHA20_POLY1305_SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=DE; ST=Some-State; O=Apache Haus Distribution Test Certificate; OU=Apache Haus Distribution Test Certificate
*  start date: Apr  6 00:21:34 2012 GMT
*  expire date: Apr  4 00:21:34 2020 GMT
*  issuer: C=DE; ST=Some-State; O=Apache Haus Distribution Test Certificate; OU=Apache Haus Distribution Test Certificate
*  SSL certificate verify result: self signed certificate (18), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x102c7e0)
> GET / HTTP/2
> Host: localhost
> User-Agent: curl/7.64.1
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 200
< date: Sun, 16 Feb 2020 23:28:19 GMT
< server: Apache/2.4.41 (Win32) OpenSSL/1.1.1c
< last-modified: Wed, 14 Aug 2019 17:48:54 GMT
< etag: "2ed8-590175ee861f0"
< accept-ranges: bytes
< content-length: 11992
< content-type: text/html

Not all ssl ciphers are HTTP/2 compatible and there is a black list. AES128-SHA must not be and sorry I didn't see it before my first answer. OpenSSL says it's a TLS/1.0 cipher so seeing TLS/1.2 connection there is strange.

The current config we ship with Apache uses these for an OpenSSL 1.1.1 build
  SSLHonorCipherOrder on
  SSLProtocol -all +TLSv1.2 +TLSv1.3
  SSLCipherSuite SSL ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:!RC4:!LOW:!MD5:!aNULL:!eNULL:!3DES:!EXP:!PSK:!SRP:!DSS
  SSLCipherSuite TLSv1.3 TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256

Take notice of the two ciphersuite lists, the SSL one is for connections TLS/1.0 - 1.2 and the TLS/1.3 is you guessed it, for TLSv1.3  :)
Also note that the order can also be important

 7 
 on: February 16, 2020, 09:15:10 PM 
Started by Gene - Last post by Gene
Thanks, Gregg, but I already have http2 module loaded.
Also I have the following directives:

<IfModule http2_module>
#    ProtocolsHonorOrder On
    Protocols h2 http/1.1
</IfModule>

# Remove when done debugging
<IfModule http2_module>
    LogLevel http2:info
</IfModule>

Gene

 8 
 on: February 16, 2020, 08:43:55 AM 
Started by Gene - Last post by Gregg
Uncomment the LoadModule line for http2 in conf/httpd.conf

 9 
 on: February 16, 2020, 12:18:13 AM 
Started by Gene - Last post by Gene
Hi folks,

I would like to enable my 32-bit Apache web server to support HTTP/2.  Currently my server support https.

I tried using both OpenSSL and Libre SSL 32-bit builds:
 httpd-2.4.41-o111c-x86-vc15-r2.zip
 httpd-2.4.41-lre302-x86-vc14.zip

The connection to the server is successful, but it is only using HTTP/1.2.

Here's the output from curl:

curl -k --http2 -v https://<my server>:9300
*   Trying <my server>:9300...
* TCP_NODELAY set
* Connected to <my server> port 9300 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / AES128-SHA
* ALPN, server did not agree to a protocol
...
> GET / HTTP/1.1
> Host: <my server>:9300
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
...

Does anybody have any suggestions?

Thanks in advance.

 10 
 on: February 15, 2020, 05:46:26 AM 
Started by JC - Last post by Gregg
We have Apache 2.4.41 with openssl 1.1.1d on our download page.
Edit: I see that is not correct, we're at 1.1.1c. I remember that the CVE didn't effect Apache but sclient but


About that CVE. Methinks (I may be wrong) that this is also yours;
https://www.apachelounge.com/viewtopic.php?p=38830#38830

But let's look at that post, at the bottom
Quote from: franklin.watson
Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.
Solution
Upgrade to OpenSSL version 1.1.1e-dev or later.

So, Nessus is blindly suggesting to upgrade to a dev version. But not just that, the fact that they are not even testing for (because no one yet knows how to screw you with it but the reporter & devs working on the fix) but are relying solely "only on the application's self-reported version number" is shameful and they just want to look like you're getting your moneys worth.

That tells me I could just change the numbers in the source of 1.1.1d and they'd shut up. It would be the same exact code but changing the numbers in 1 file (opensslv.h) would be enough to satisfy them.  ::) They're crying WOLF WOLF WOLF! but haven't bothered to actually see if it is indeed around.

If that post isn't yours, we don't do dev releases except for dev purposes, that's why they are "dev versions," certainly not for production severs. If you 'just have to fix this it probably is a production server.

Compiling OpenSSL in and of itself is two lines at the command line and not that hard. Just replace the DLLs in Apache24/bin. You only need Perl, NASM & the free version of visual studio that matches your Apache.

Code: [Select]
perl Configure VC-WIN64A --prefix=/Apache24 --openssldir=/Apache24/conf enable-camellia no-idea no-mdc2 no-ssl2 no-ssl3 no-zlib
nmake

That way you can have the fix for any other low severity, not very likely to be abused, vulnerability that doesn't warrant an actual release for next time the boy cries wolf.



Pages: [1] 2 3 ... 10