According to this site: http://search.cpan.org/~mramberg/Catalyst-Plugin-RequireSSL-0.07/lib/Catalyst/Plugin/RequireSSL.pm
It's as easy as this:
# in MyApp.pm
use Catalyst qw/
RequireSSL
/;
__PACKAGE__->config(
require_ssl => {
remain_in_ssl => 0,
no_cache => 0,
detach_on_redirect => 1,
},
);
__PACKAGE__->setup;
# in any controller methods that should be secured
$c->require_ssl;
However, I am running the app using the built in MyApp_server.pl . And when I follow those instructions I get an SSL connection error Error code: ERR_SSL_PROTOCOL_ERROR
I'm guessing that the MyApp_server.pl doesn't support SSL, or there is more that I need to do to configure it.
Can I set up an SSL connection using nginx? I can find now instructions on how to do this. Can this be done with Apache?
Frankly, I was really hoping to be able to deploy this app with the built in server, but SSL encryption is required for all of my pages.
Thanks for any help that you can provide!
PS This app is running on my personal computer (OSX) behind a firewall, but the intention is to deploy it on a linux server behind a firewall.
Related
I am using Ratchet WebSocket in a Windows-based server project that is entirely working in an insecure environment. That is to say that when I navigate my browser to http://www.example.com and connect to the websocket server using ws:// on port 8686 everything works spectacularly.
The server doesn't run through IIS - but instead is executed via php.exe in command prompt like this.
php wsocket-server.php [...parameters...]
However, if run the Ratchet Server and try to connect from https://www.example.com using wss:// the browser simply will not connect to the websocket server, despite the fact that the server starts up fine and the insecure site and connect via ws://
Now, I realize I need to utilize some additional code to include my SSL documentation. This is the relevant code I have in place:
use Ratchet\Server\IoServer;
use Ratchet\Http\HttpServer;
use Ratchet\WebSocket\WsServer;
$websocket_server = new WsServer();
if ($site_secure){
//RUN WSS (SECURE) SERVER
$options = [
'local_cert' => 'c:\inetpub\ssl\2c6fa1928847451c.crt',
'local_pk' => 'c:\inetpub\ssl\2c6fa1928847451c.key',
'allow_self_signed' => true,
'verify_peer' => false
];
$loop = React\EventLoop\Factory::create();
$websocket_server->enableKeepAlive($loop);
$app = new HttpServer($websocket_server);
$insecure_websockets = new \React\Socket\Server('0.0.0.0:'.$port, $loop);
$secure_websockets = new \React\Socket\SecureServer($insecure_websockets , $loop, $options);
$secure_websockets_server = new \Ratchet\Server\IoServer($app, $secure_websockets, $loop);
$secure_websockets_server->run();
}else{
//RUN WS (INSECURE) SERVER
$http_server = new HttpServer($websocket_server);
$server = IoServer::factory($http_server, $port);
$websocket->log ("Initializing ".(($site_secure) ? "Secure " : "Insecure ")."Server ($port)");
$server->run();
}
What I have tried
I have ensured the correct ports are all open in the windows firewall.
I have ensured nothing else is listening on the port using netstat
I have tried using nginx, on a minimal level. I'd prefer to NOT use this method if possible, and was having some initial problems with it starting up so I did not dedicate 100% to it at this time. Ideally, I'd like to use Ratchet's native abilities.
I have searched other similar posts both here and elsewhere, such as this.
I have tried a number of different ports, even the same 8686 as I use in the insecure connection
I am hoping someone can lend me an assist with an issue that has been driving me crazy for 2 weeks. At this point I feel like I'm just trying things to try them and I may be coding myself in circles.
Thank you in advance.
A browser is never going to connect to anything running on port 465. Especially not a WebSocket.
Establishing a WebSocket connection is specified in terms of the Fetch standard. As such, the specific exclusion of this port is found within the latter:
A port is a bad port if it is listed in the first column of the following table.
Port
Typical service
…
…
465
submission
…
…
Now, why are some ports blacklisted? This is a protection against cross-protocol scripting attacks, as once demonstrated (warning: NSFW links) against Firefox and against Safari. Port 465 has been (and still sometimes is) used for SMTP over (pure) TLS, so in this case, an XPS attack might trick a browser into sending mail on the user’s behalf. Blocking those ports is meant to prevent it. Of course, all bets are off when a service runs on a non-standard port.
To make the service available in a browser, all you need to do is change the port number.
I'm new to Progressive Web Apps, and I'm adding a Service Worker to my app for the very first time. It's a simple Service Worker, with my goal being purely to test that it is being registered properly. The file is serviceWorker.js:
console.log('Hello Service Worker');
I'm adding this to an application that I'm running with the Webpack Dev Server. I'm using a self-signed certificate locally with it. I setup the Service Worker in my index.tsx (React Typescript) like this:
if ('serviceWorker' in navigator) {
navigator.serviceWorker
.register('/service-worker.js')
.then(() => console.log('Worker registered'))
.catch((ex) => console.error('Worker registration error', ex));
}
However, when I start the dev server and go to the app, I get an error:
Failed to register a ServiceWorker for scope ('https://localhost:3000/') with script ('https://localhost:3000/service-worker.js'): An SSL certificate error occurred when fetching the script.
The URL, https://localhost:3000/service-worker.js, does indeed work, the browser is just blocking it because of the self-signed piece of the cert.
I'm using Chrome Browser on on M1 Pro MacBook running MacOS Monterey, with Webpack 5.
For the record, I'm aware of plugins like Workbox, I would prefer not to use them at this time because I'm still very new to Service Workers. I believe in working with the low-level constructs when starting with a new tech to understand them better before embracing easier abstractions.
I'm not aware of any features—including service workers—that require HTTPS on localhost.
localhost, and equivalent IP address ranges, are specifically excluded from HTTPS requirements by Chromium-based browsers, and both Firefox and Safari follow that, at least when it comes to service workers.
So I would suggest that you just access your web site via http://localhost:3000 instead.
There are more details in this older answer.
I am new to ASP.Net core and I am trying to get a new ASP.NET core app started on my machine (Windows 8.1). I am following the tutorial at https://learn.microsoft.com/en-us/aspnet/core/getting-started/?view=aspnetcore-3.1&tabs=windows (which is about as basic as it gets):
Create the application via: dotnet new webapp -o aspnetcoreapp
Trust the cert via: dotnet dev-certs https --trust
Run the application via: dotnet watch run
When I run the application and I navigate to https://localhost:5001/ in Chrome, I receive the following error:
This site can’t be reached
The webpage at https://localhost:5001/ might be temporarily down or it may have moved permanently to a new web address.
ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY
This feels like a cert issue to me, so I followed the link under "Trust the development certificate section", and I tried to remove and re-add the old cert via:
dotnet dev-certs https --clean
dotnet dev-certs https --trust
But that didn't help.
I do not see any errors when I run dotnet watch run. This is the output:
watch : Started
info: Microsoft.Hosting.Lifetime[0]
Now listening on: https://localhost:5001
info: Microsoft.Hosting.Lifetime[0]
Now listening on: http://localhost:5000
info: Microsoft.Hosting.Lifetime[0]
Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
Content root path: D:\learn_code\aspnetcoreapp2
I downloaded the new version of .NET yesterday and tried again, so I don't think it's a version issue. I'm using 3.1.402.
Is there something else I can do to get this running? Thanks.
Update:
This Microsoft article has helpful information, but it also states that Windows 8 and 8.1 have TLS 1.2 enabled and on by default:
https://learn.microsoft.com/en-us/dotnet/framework/network-programming/tls#configuring-security-via-the-windows-registry
I also tried the recommended registry settings, but that didn't work, and I think this might be targeted at .NET Framework and not necessarily .NET Core (but I'm not 100% sure about that)...
Also, there's a little bit more going on with HTTP2 as well. I found this article, which seems to imply it's the ciphers in combination with HTTP2:
https://www.tecklyfe.com/how-to-fix-ns_error_net_inadequate_security-and-err_spdy_inadequate_transport_security-in-iis-on-windows-server-2016/
I tried the Nartac IISCrypto GUI tool (which is MUCH easier than editing registry settings by hand) https://www.nartac.com/Products/IISCrypto/Download, clicking on the Best Practices button and rebooting, but that didn't work.
There was one other recommendation in the tecklyfe article with disabling HTTP2 in Firefox, and that did work. So, I think the answer is probably somewhere in the realm of using the correct cipher.
dotnet run looks like it's launching in Microsoft.Hosting.Lifetime, so maybe I can figure out how to configure that?
According to this Microsoft article https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1#:~:text=Kestrel%20is%20a%20cross%2Dplatform,ASP.NET%20Core%20project%20templates. in the section "HTTP/2 support",
Kestrel has limited support for HTTP/2 on Windows Server 2012 R2 and
Windows 8.1. Support is limited because the list of supported TLS
cipher suites available on these operating systems is limited. A
certificate generated using an Elliptic Curve Digital Signature
Algorithm (ECDSA) may be required to secure TLS connections.
In order to run an ASP.Net Core app on Windows 8.1, configure Http1 as the default connection protocol, by adding this configuration to your appsettings.json file:
"Kestrel": {
"EndpointDefaults": {
"Protocols": "Http1"
}
}
Try to add Protocols into Kestrel COnfiguration
ConfigureKestrel((context, options) =>
{
// development options for kestrel
if (context.HostingEnvironment.IsDevelopment())
{
options.Listen(IPAddress.Any, 5000); // http:localhost:5000
options.Listen(IPAddress.Any, 5001, listenOptions =>
{
listenOptions.Protocols = Microsoft.AspNetCore.Server.Kestrel.Core.HttpProtocols.Http1; // force http1 during dev.
//install certificate with private key
listenOptions.UseHttps(#"S:\Certs\SSL\example.com.pfx", "1234567", httpsOptions =>
{
httpsOptions.SslProtocols = System.Security.Authentication.SslProtocols.Tls;
});
});
}
});
When trying to connect NextCloud to OnlyOffice's document server, an error is thrown, but not much else is provided in order to fix the issue.
As shown below, the server is running properly, on HTTPS (see this SO question for steps followed to set up certificate), and on a different server.
Docker instances have been reset, all should be working as per documentation.
Is the issue on the NextCloud or OnlyOffice side? What could be done to fix this issue?
You can try adding Let’s Encrypt Authority X3 intermediate certificate to the DocumentServer or
'onlyoffice' =>
array (
'verify_peer_off' => TRUE,
)
to the /var/www/nextcloud/config/config.php
BTW your document server is accessible from outside network.
We would recommend to enable JWT
I have been at this for days and I can't seem to find the solution for this. I have a live website, and I recently installed the ssl certificate and made the website available on https.
What's really strange is that at first the website worked well on https. For about a day or so it was live and working well. But then the next day I checked and the site is now giving me this error:
WebSocket connection to 'wss://domain.com/sockjs/421/dto72qfy/websocket' failed: WebSocket is closed before the connection is established.
The navigation bar loads and the sidebar loads, but the content doesn't, it's just stuck in the 'loading' template. If I check the domain in http the website is working fine.
I am using meteor up (mup) to upload the site and digital ocean. One of the few things I have changed was the mup.json
...
// Configure environment
"env": {
"ROOT_URL": "https://website.com/"
//"PORT": 80
},
"ssl": {
"pem": "./ssl.pem"
//"backendPort": 80
},
...
I'm not sure how to deal with websockets and why they only have problems in https. If anyone has gotten their meteor app to work with mup and ssh I would really appreciate some help.
You can disable websockets by adding the following environmental variable in your mup.json
"DISABLE_WEBSOCKETS"=1
If you don't want to disable websockets, you can try option 2 from here.
We have websockets disabled on https://saturnapi.com; you can see yourself if it is usable. Others have also reported that disabling websockets still allow for a usable app, albeit a bit slower. It should depend on how your app is configured, so I recommend giving it a try and reverting to the other solutions if it doesn't work.