Some phones only prompt the user for permission the first time a connection is made. Others pop up the permission prompt whenever the MIDlet attempts to make a HTTP connection! What are the options if we want to suppress the prompt?
Can we sign the JAR using only one CA (Certificate Authority) and have it work on all devices? Do we have to pay for a signature on every release?
Is it an option to create our own CA certificate and tell our customers to install it on there device?
Alternatively, it seems that plain socket connections do not suffer so. Is there a free implementation of HTTP on top of TCP for J2ME?
Some phones allow you to change the setting manually to set once per session. Or try adding
MIDlet-Permissions: javax.microedition.io.connector.http
to the jad file.
Yes, if the build is signed with the root certificate that is available on most devices, Verisign Class 3 certificate, for example
As a security measure, devices don't allow you to install your own certificates, even if it is obtained from a CA.
Plain socket connections may add overhead in processing of the data in the client side. Also some security issues are also involved.
Signing the JAR is not guaranteed to suppress these prompts on all handsets and all networks. It may work on some. AFAIK you usually need to sign per build; so if you use the same build on many handsets, you need to sign only once.
You could write your own implementation of HTTP over sockets, but beware that Socket implementations do not allow access to ports 80 and 8080 (again AFAIK).
Your best option when experiencing multiple prompts for HTTP is to direct the user to the MIDlet permissions setting in their handset menu; this should be changed to "ask once".
HTH,
funkybro
Java Verifieds UTI root certificate is not on all handsets/network combinations, the same is true for other domains in the trusted third party such as Verisign and Thawte (for these bodies in particular Motorola devices)
It is fair to say that the UTI certificate is probably the one to choose to give you the most coverage across handsets
To suppress the HTTP connection prompt, signing an app is the only option. Another would be to get preload on a pre-market phone, but even the handset manufacturers require signed jad/jars.
Making a set of jad/jar work on different devices is not dependent on signing but how you design an app. If you can address this then yes, you can have one signed jad/jar work on multiple devices.
I do not know about creating our own certs and asking customers to install them. I dont think it works as I dont think it is possible.
HTTP over TCP is a fairly easy implementation, provided you know what you are doing, but I dont know of any free implementations of it.
Get it Java Verified and you will find that on all networks and phones - the user will get prompted only once each time they start the app to authorise a connection.
Related
I'm setting up my first server on a Raspberry Pi 4 but after reading some articles online I was wondering whether my server is ready to be open to the internet or not. I premise I'm just an individual who would like to publish some programming projects on a site that is accessible on a browser.
After some concerns I designed a PHP page which checks the client IP and returns a 403 header until i give that user the permission to access. Is it enough? Is it necessary?
And also, are there ports that are more safe to open than others?
You "can" open ports 80 and/or 443 for displaying webpages - depending on SSL certificates
I do it myself (not for web hosting) and restrict the open ports to certain IPs - my friends (not smart enough to levy an attack 😂). Though IPs are likely to change every so often and your firewall will need updating.
It's a key thing to remember that anything is open to exploitation if it's not properly maintained/set up. Also displaying a 403 isn't a silver bullet.
Port 25 would give a user access to the files on your device if proper authorisation isn't set up. Opening ports 80 and 443 will give users access to webpages but makes your device/network exposed to DoS attacks or platform level attacks. If there's a known exploit for your version of PHP or your firewall/router or possibly the device itself then an attacker will exploit it.
Hosting providers have layers upon layers of security and are constantly updating devices throughout their network. Keeping your device and platform up to date will help - but it may be worth instead investing a little in a host (from about £4 a month).
There are loads more things I can touch on but will leave it at that for now
Edit after comment:
my website is just a little project i mean who could casually target it?
Strictly speaking, anyone. "Who would want to?" Again, anyone. Sure you're a small target that wouldn't provide any useful data. But your device, once hacked, can be used as a DoS zombie or as a crypto-miner and you probably wouldn't even realise.
And also can't I use whatever port like 6969 or 45688?
Yes, strictly speaking, you can. You could tell your device to listen on that port and reply with the website data. To do this you would also need to provide the port number on the end of the URL in the format www.example.com:6969. Though, again, this isn't a silver bullet. Most security issues aren't with port-forwarding but with poor management/security and bugs in the components themselves. All a port forwarder is doing is saying "oh, device X wants data on this port... here you go".
Another point is, data sent on "Well-known ports" (1-1023) tend to have their headers checked for irregularities by the firewall - which can dispose of any irregular packets. By using a custom port the firewall doesn't really know what to expect, so it sends it anyway. Also, steer away from "Private ports" (49152-65535) these are used as source ports, not destination ports.
Hello Corda experts: I have a question about Conclave beta 3. I downloaded conclave SDK hello world project, and ran it according to conclave document successfully. But when I tried to use RestTemplate to access an external https API from the enclave, it is failed. And the error message is "java.security.NoSuchAlgorithmException: Default SSLContext not available". Since the default JVM for enclave is Avian, I doubt that maybe Avian doesn't support SSL. Does any expert know the root cause and how to solve it? Thanks very much.
At this time Conclave doesn't support outbound SSL connections. It's something we'd like to support and is a high priority but it must be done very carefully. For example, we will have to ship a root cert store with the enclave embedded in the binary (or a signed version that's injectable by the host), there are questions about how to handle expiry checking given that the host controls the clock, whatever credentials are used to access the external service (if any) need to be securely sealed and stored, it will only make sense to support OCSP Stapling as a form of revocation checking with all others needing to be disabled and so on.
You don't technically need us to solve these issues for you. You can load the SSLEngine and relay packets from it in and out of the host using the call mechanism. It'd be a bit awkward but should be possible.
I want to know which options exist to provision (configure) multiple VoIP phones from multiple vendors for use with an Asterisk server. I'd like some kind of interface to manage extensions, configuration templates and so on.
Here's what I found so far:
FreePBX has a commercial module called Endpoint Manager which seems to do what I want. However, I don't like the idea of having to run a web server on the same machine (or container) that runs Asterisk. It seems like a bad idea which increases the attack surface of the Asterisk server. I would much rather have an endpoint manager on a separate server (or container) but I can't find any information about running or buying the Endpoint Manager outside of FreePBX.
Phonism advertises a "Cloud based IP phone provisioning and management system. Their service looks promising, but the number of supported phones is lower and I'm not completely sold on requiring the internet connection to configure the phone extensions in an office.
All the other solutions I found are tied to their complete proprietary VoIP solution (3CX, Kerio, etc.) or to a particular VoIP phone vendor.
Is anything else available? Or do people usually use a single VoIP phone vendor and use their own specific configuration method?
Since I can't find any phone provisioning solution which fits my needs, I'm questioning my understanding of Asterisk deployment best practices. Is using a plain Asterisk deployment a good idea or is it too bare in terms of related tooling?
You are thinking about this in a way that is too abstract and generic.
A voip equipment vendor will provide documentation which describes what provisioning protocols are used and how to use them. Then you can find a tool to use which meets that requirement and also suits your environment and skills.
Vendors usually provide proprietary tools to generate provisioning files too.
That said you should be advised that TFTP (trivial file transfer protocol) is a common provisioning method.
If you are using a bare bones asterisk install on linux then setting up your own TFTP server on linux is, well, trivial in comparison.
Running a provisioning server and asterisk server on different boxes is of course possible but you'll need to find or build some integration tools to keep provisioning config and asterisk config in sync (if that's important to you). I can't think of a reason why using two boxes makes this work significantly more difficult though.
When using java APNs, if using the same program to send messages to different applications, it is required to use different certificates. Does switching certificates causes disconnection/reconnection and is it considered a bad practice? (as APNs would like to have persistent connections thus preventing denial of service).
I don't think it's possible to switch a certificate for an existing connection. At least I'm quite sure it's not possible in Java SSLSocket (since it is constructed by an SSLSocketFactory, and you use the certificate in one of the parameters required for constructing that factory).
You should maintain an open socket for each application you are sending notifications to. This way you don't have to close the socket and open a new one each time you need to switch certificates.
So, considering the pricing for SSLs, I chose to try creating my own SSL certificate (still in the works).
Once I get that part done, how to I get the EV and green bar aspect of the certificate set up?
It can make sense to create your own certificates (and use your own CA) if you're in an environment where your users can import your own CA certificate in a way they can verify it independently. Typically, this works fine on an institution's network where someone installs the extra CA certificate as part of the OS configuration when configuring centrally-administered machines (and similar cases). Under these conditions, this will get you a blue bar without any problem.
Extended Validation certificate (which produce a green bar) rely on two things:
Extra policy attributes in the certificate: technically, you could define some OIDs yourself, although getting others to recognise it will be a problem, obviously.
OID policies and root certificate fingerprints that are hard-coded in the browser.
This second point is what will prevent you from doing it yourself. Non-EV certificates is something you could potentially implement on machines under your control using a few extra configuration steps. EV certificates also require that you control the compilation of the browser: this is not going to happen for proprietary browsers such as IE, and it can still be quite a lot of work for open-source browsers (e.g. Firefox/Chromium), since you wouldn't be able to rely on the pre-compiled binaries (and you'd have to recompile it yourself for every new release).
I think you're probably going to find that all that nice stuff (assuming you are talking about the padlock and green bar in the browser) depends on the other part of certification, the fact that the certificate has been issued by a trusted provider who has verified your identity - this you probably can't do on your own.
The whole idea of SSL certificates is that somebody everybody trusts (mozilla, microsoft) certify certifiers (thawte etc) to certify sites they audit (somehow) as being genuine. This wont work with your certificate, the idea is a trust chain. microsoft trusts thawte, they trust you. Nobody trusts you in your case so your self-signed certificate means nothing to browsers.